AMCS Product Definition¶

The canonical commercial definition of AMCS: what it is, who buys it, what they buy, how it is positioned, priced, sold, measured, and killed.

This file does not restate architecture. Architecture.md is the technical authority and is not duplicated here. Vision.md owns the product thesis, Roadmap.md the sequence, and Status.md observed maturity. Where this file needs an architectural fact it cites the owning section rather than repeating it.

How to read the evidence tags¶

Every factual claim in this file carries one tag. Untagged assertions are prohibited.

Tag	Meaning
`CANONICAL_POLICY`	A decision recorded in governed Bluefly doctrine. Binding until changed by the same authority.
`CURRENT_SOURCE`	Read from tracked source on `blucity-docs release/v0.1.x`, or from another named repository's tracked source.
`RUNTIME-VERIFIED`	Observed in a running system, with the observation named.
`NOT_ESTABLISHED`	Not proven. Explicitly not a soft yes.

A claim tagged CURRENT_SOURCE establishes what a document says. It does not establish that the described thing runs. See success-is-the-effect for why those are different.

1. Executive decision table¶

Field	Value	Tag
`PRODUCT_NAME`	AMCS — Agent-Managed Content System	`CANONICAL_POLICY` (operator direction, 2026-09-14)
`PRODUCT_TYPE`	`COMMERCIAL_PRODUCT`	`CANONICAL_POLICY`
`PRODUCT_FAMILY`	Bluefly governed Drupal products. AMCS is the first and currently only member with a customer-facing definition.	`CURRENT_SOURCE` — `Vision.md`, `Architecture.md` §4
`PRODUCT_OWNER`	See §1.1. Not resolvable from tracked source; rendered there as an explicit operator decision slot.	`OPERATOR_DECISION_REQUIRED`
`ONE_SENTENCE_DEFINITION`	AMCS is a customer-owned Drupal content system in which AI agents can perform real content work inside Drupal's permissions, revisions, workflows and approval boundaries without becoming a second CMS or receiving uncontrolled production authority.	`CANONICAL_POLICY` (operator direction, 2026-09-14)
`COMMERCIAL_CATEGORY`	Agent-Managed Content System. Not "AI CMS".	`CANONICAL_POLICY`
`CURRENT_MATURITY`	Prototype / MVP, narrow vertical.	`CURRENT_SOURCE` — `Status.md`, "Maturity Level: Prototype / MVP (narrow AMCS vertical)"
`PRIMARY_DECISION`	Prove one paid customer running one meaningful agent-assisted content workflow across a protected publication boundary, before any second vertical, second product, or marketplace surface.	`CANONICAL_POLICY` — `Roadmap.md` Phase 1; platform-glossary Commercial Model

OPEN DECISION, carried at the top so it cannot be missed. A canonical entry of equal standing — the Founder-locked Commercial Model in platform-glossary.md (2026-08-24) — describes AMCS as the demonstration of a governed-modernization motion rather than as the product. This file is written to the operator direction of 2026-09-14, which makes AMCS the product. Both are live and only the Founder-locked authority can retire either. Full statement of the conflict, and what it does and does not affect, in §20 finding 4. Do not resolve it by quoting this file.

1.1 Ownership¶

A product definition must identify who owns the product, its engineering, its runtime, its documentation and its commercial outcome. Some of these may be the same entity; where they are, this says so rather than implying it.

Two states are used here and they are not the same thing:

RESOLVED_FROM_SOURCE          tracked source answers this. Ref and path cited.
OPERATOR_DECISION_REQUIRED    tracked source does not answer this, and no probe
                              can. A person must decide it.

OPERATOR_DECISION_REQUIRED is deliberately not NOT_ESTABLISHED. NOT_ESTABLISHED means nobody has proven this yet and is discharged by evidence (§19). A decision slot is discharged only by a decision. Conflating the two is how this gap survived: an unassigned owner sat in a table of epistemic states, where it read as something a future measurement would resolve. No measurement will.

Field	State	Value	Evidence / decision slot
`DOC_OWNER`	`RESOLVED_FROM_SOURCE`	Product Team for `Vision.md`, `Status.md`, `Roadmap.md` and this file; Architecture Team for `Architecture.md`.	Front matter `owner:` on each file, `blucity-docs release/v0.1.x:products/AMCS/.md`. `AUTHORITY-MATRIX.md` product table assigns the AMCS canonical file set. These are role labels, not persons* — see the constraint below.
`ENGINEERING_OWNER`	`RESOLVED_FROM_SOURCE` for where; `OPERATOR_DECISION_REQUIRED` for who	The owning projects are `recipe_blucity`, `recipe_amcs` and `site_template_amcs`.	`AUTHORITY-MATRIX.md` rule: "Implementation stays with the owner: BluCity-Docs defines doctrine and product architecture; source implementation belongs in the owning project." But `Engineering-Standard/authority/Portfolio-Registry.yaml:1209-1218` lists all three repositories as `status: NOT_REVIEWED`, `product: null` — the repositories are named and their accountable owner is not.
`RUNTIME_OWNER`	`RESOLVED_FROM_SOURCE` for delivered instances	The customer. AMCS runs on customer-owned Drupal; Bluefly does not operate the customer's runtime.	`Architecture.md` §5 (Drupal runs the product, Gas City manufactures it); §39 (source, checkout, runtime and work authority are distinct). Reinforced commercially in §2 row 5 and §17 of this file.
`RUNTIME_OWNER` (Bluefly-operated demo or reference instances)	`OPERATOR_DECISION_REQUIRED`	—	No host is named in tracked source, which is the same gap §19.2 records as production verification `NOT_ESTABLISHED`. Naming the host is a decision; verifying it is then a probe.
`PRODUCT_OWNER`	`OPERATOR_DECISION_REQUIRED`	—	No tracked source names an accountable owner for the AMCS product as a whole. `Portfolio-Registry.yaml:125-131` carries `id: AMCS`, `status: ACTIVE`, and `roadmap: null`, `pricing: null`, `customers: null` — the registry has the slots and they are empty. AMCS appears zero times in all three governance ownership matrices (positive control: control terms fire 3 / 12 / 2 in those same files, so the probe reads them).
`COMMERCIAL_OWNER`	`OPERATOR_DECISION_REQUIRED`	—	Nothing in tracked source assigns accountability for AMCS pricing, packaging or revenue. Consequence, stated plainly: every pricing and packaging statement in §13 and §14 is a planning hypothesis that nobody is currently empowered to ratify.

The decision slots, as slots¶

Each of these is a named field awaiting assignment by the operator. They are not research tasks and no agent may fill them.

PRODUCT_OWNER                    = UNASSIGNED   awaiting operator, opened 2026-09-14
COMMERCIAL_OWNER                 = UNASSIGNED   awaiting operator, opened 2026-09-14
ENGINEERING_OWNER (accountable)  = UNASSIGNED   awaiting operator, opened 2026-09-14
RUNTIME_OWNER (Bluefly demo)     = UNASSIGNED   awaiting operator, opened 2026-09-14

When assigned, record the assignment here with its date, and reconcile Portfolio-Registry.yaml's empty AMCS slots in the same change.

The constraint that makes the role labels less than they look¶

OWNERSHIP.md at the repository root states that the GitLab human identity is username bluefly only, and that CODEOWNERS and approvals are "@bluefly and no other users". RESOLVED_FROM_SOURCE.

So "Product Team" and "Architecture Team" are document-level role labels, not distinct accountable parties — today they resolve to one GitLab identity. Recording that is not pedantry: a definition that lists four owner roles while one account holds all of them has described an intention, not a separation of duties. The slots above are what would make it real.

The governing correction this file exists to land¶

AMCS = AGENT MANAGED CONTENT SYSTEM. IT IS THE PRODUCT.
AMCS OWNS GOVERNANCE. THERE IS NO SEPARATE "DRUPAL AGENT GOVERNANCE" PRODUCT.
AMCS IS WHAT THE CUSTOMER OPERATES.
SITE FACTORY / GAS CITY IS HOW BLUEFLY MANUFACTURES IT.
CONTEXTCONTROL GOVERNS THE BROADER AGENT OPERATION AND IS SEPARATE.

CANONICAL_POLICY (operator direction, 2026-09-14).

The fundamental law, unchanged from Architecture.md §1 and restated here because it is the commercial promise as well as the engineering one:

Agents act inside Drupal authority. They do not create a second authority.

2. What the customer actually buys¶

The customer buys outcomes in their own content operation. Seven problem rows, each stated as the customer would state it.

#	Customer problem	Outcome purchased
1	"We want AI help with content, but nobody will accept an AI that can publish."	A publication boundary that is enforced by Drupal permissions and workflow transition access, not by prompt instructions. `CURRENT_SOURCE` — `Architecture.md` §12, §23.
2	"Our editorial QA is manual, inconsistent, and the first thing dropped under deadline."	A repeatable QA pass that runs on every qualifying revision and produces specific, actionable findings rather than a pass/fail verdict. `CURRENT_SOURCE` — `Architecture.md` §13, §31.
3	"We cannot tell what the AI did, or why."	Findings, agent identity and execution lineage recorded as ordinary Drupal revisions, moderation history and workflow execution records — readable by the customer's own editors, not by a vendor. `CURRENT_SOURCE` — `Architecture.md` §25.
4	"Every AI tool we have tried became another system to administer."	Agent capability delivered as Drupal configuration inside the site the customer already operates. No second content store, no second permissions model, no second publication state. `CURRENT_SOURCE` — `Architecture.md` §1.
5	"We are locked into whoever built it."	Customer owns the repository, data, content, configuration and deployment path; exit assistance and a tested handoff are part of the product. `CURRENT_SOURCE` — governed-product-factory doc §17.
6	"Our site drifts, and upgrades are a project every time."	The site is reproducible from its own repository — recipes and a site template, not a hand-assembled snowflake. `CURRENT_SOURCE` — `Architecture.md` §33, §34.
7	"We need this to keep working after launch."	Recurring assurance: security and release management, regression, evidence, and improvement capacity against the running service. `CURRENT_SOURCE` — governed-product-factory doc §15, "Foundation Operate".

What the customer does NOT buy¶

AI Agents        FlowDrop        Tool API        MCP
Gas City         Beads           Formulas        Cedar
vector DBs       model tokens    agent seats     prompt orchestration

CANONICAL_POLICY — Vision.md Core Operating Rule: "Bluefly does not sell commodity LLM routers, agent runtimes, tracing systems, service meshes, or Gas City seats." Reinforced by platform-glossary Commercial Model (Founder-locked, 2026-08-24): the motion is governed modernization outcomes, "not a marketplace/orchestration-seat product."

These are real and load-bearing. They are inputs to the product, not line items on an invoice. A customer who is being sold Tool API is being sold Bluefly's implementation detail, which is the failure mode this section exists to prevent.

3. Product / substrate classification¶

Every component named across the AMCS source material, classified. The classification is the durable content. The names in the PROJECT_OR_REPOSITORY column are implementation and are expected to change — see §3.1.

Component	Classification	Note
AMCS	`COMMERCIAL_PRODUCT`	The thing the customer operates. `CANONICAL_POLICY`.
Modernization Readiness / Lane Pilot / Portfolio / Foundation Operate / Expansion Pack / Shared District Edition	`COMMERCIAL_OFFER`	The six offers already defined in governed-product-factory doc §15. Not re-specified here. `CURRENT_SOURCE`.
Governed agent content work inside Drupal	`CUSTOMER_CAPABILITY`	What the customer's editors and agents actually do.
Protected publication boundary	`CUSTOMER_CAPABILITY`	Enforced by Drupal permissions. `CURRENT_SOURCE` — `Architecture.md` §12.
Editorial QA pipeline	`CUSTOMER_CAPABILITY`	Owned by the workflow engine, not by an agent loop. `CURRENT_SOURCE` — `Architecture.md` §13.
`recipe_blucity` (foundation recipe)	`BLUEFLY_COMPOSITION`	Shared Drupal foundation. `CURRENT_SOURCE` — `Status.md`.
`recipe_amcs` (domain recipe)	`BLUEFLY_COMPOSITION`	AMCS content model, roles, moderation, QA workflow. `CURRENT_SOURCE` — `Status.md`.
`site_template_amcs` (installable product)	`BLUEFLY_COMPOSITION`	Installer-facing assembly. `CURRENT_SOURCE` — `Architecture.md` §4.3.
`recipe_digital_service_baseline`	`PROJECT_OR_REPOSITORY`	Sibling Site recipe. Not nested under AMCS. `CURRENT_SOURCE` — `Architecture.md` §4.4.
Drupal CMS / Drupal core	`UPSTREAM_PLATFORM`	Product base. `CURRENT_SOURCE` — `Architecture.md` §3.
Drupal AI (`drupal/ai`)	`UPSTREAM_PLATFORM`	Provider abstraction. No direct SDK calls. `CURRENT_SOURCE` — `Architecture.md` §10.
AI Agents (`drupal/ai_agents`)	`UPSTREAM_PLATFORM`	Drupal-native agent definitions. `CURRENT_SOURCE` — `Architecture.md` §11.
FlowDrop (`drupal/flowdrop`)	`UPSTREAM_PLATFORM`	Multi-step runtime workflow owner. `CURRENT_SOURCE` — `Architecture.md` §13.
ECA (`drupal/eca`)	`UPSTREAM_PLATFORM`	Bounded reactions, not the QA graph. `CURRENT_SOURCE` — `Architecture.md` §15.
Content Moderation / Workflows (core)	`UPSTREAM_PLATFORM`	Publication authority. `CURRENT_SOURCE` — `Architecture.md` §12.
Canvas + SDC	`UPSTREAM_PLATFORM`	Page composition. `CURRENT_SOURCE` — `Architecture.md` §22.
Tool API / Tool Belt / AI Context / MCP Server	`UPSTREAM_PLATFORM`	Maturity-gated. Adoption is a decision, not a default. `CURRENT_SOURCE` — `Architecture.md` §3, §17-19, §21.
Search API	`UPSTREAM_PLATFORM`	Search and index abstraction. `CURRENT_SOURCE` — `Architecture.md` §20.
OSSA	`OPEN_STANDARD_OR_PROTOCOL`	Portable agent contract. Interoperability, not Drupal content authority. `CURRENT_SOURCE` — `Architecture.md` §26. Not an MVP gate, but present: `recipe_amcs` hard-requires `drupal/ai_agents_ossa` and the demo enables it. "Not required" and "not present" are different claims — see §19.2.
DUADP	`OPEN_STANDARD_OR_PROTOCOL`	Discovery. Discovery does not grant permission. `CURRENT_SOURCE` — `Architecture.md` §26. Measured absent at both the recipe and demo layers — see §19.2.
MCP (the protocol)	`OPEN_STANDARD_OR_PROTOCOL`	Edge protocol. Not a business-logic layer, and not an AMCS prerequisite. `CURRENT_SOURCE` — `Architecture.md` §21. Measured: 0 MCP modules enabled in the demo.
Cedar	`INTERNAL_FACTORY_ASSET`	Additional external/ABAC policy where a concrete requirement and owner exist. Not an AMCS prerequisite. `CURRENT_SOURCE` — `Architecture.md` §25. Measured: 0 Cedar modules enabled in the demo, and the `authorization` policy type is populated with zero authorization policies — see §19.3 defect 4.
ContractPlane	`INTERNAL_FACTORY_ASSET`	External proof/evidence where a requirement justifies it. Not the default AMCS proof ledger, and not the revenue anchor whatever superseded sales copy says. `CURRENT_SOURCE` — `Architecture.md` §25, `Status.md:69`. Measured: 0 enabled in the demo.
Gas City / Beads / packs / formulas / orders	`INTERNAL_FACTORY_ASSET`	How Bluefly manufactures. Never the customer's editorial runtime. `CANONICAL_POLICY` — `Architecture.md` §5, §37.
ContextControl	`COMMERCIAL_PRODUCT` (separate)	Organizational learning across the broader agent operation. See §5. `CURRENT_SOURCE` — `Vision.md`.
Kagent	`INTERNAL_FACTORY_ASSET` / optional integration	Not the AMCS runtime. `CURRENT_SOURCE` — `Status.md`.
MemoryPlane, AMC Bundles, Evidence Cloud, Certification Program	`NOT_ESTABLISHED`	Named only in superseded 2026-05 sales material (see §20 classification table). No canonical definition exists. Do not sell.

3.1 Implementation mapping table — EXPECTED TO CHANGE¶

The rows above that name a repository, package, recipe or module are the current implementation of a durable capability boundary. Treat this table as volatile. The capability boundary is the architecture; the name is not.

Durable capability boundary	Current implementation (2026-09-14)	Authority for the current name
Shared Drupal foundation	`recipe_blucity`	`CURRENT_SOURCE` — `Status.md`
AMCS domain capability	`recipe_amcs`	`CURRENT_SOURCE` — `Status.md`
Installable customer product	`site_template_amcs`	`CURRENT_SOURCE` — `Architecture.md` §4.3
Multi-step editorial QA runtime	FlowDrop `^2.5`	`CURRENT_SOURCE` — `Status.md`
Bounded event reactions	ECA `^3.1`	`CURRENT_SOURCE` — `Architecture.md` §3
Provider abstraction	`drupal/ai` `^1.4`	`CURRENT_SOURCE` — `Architecture.md` §3
Manufacture method	Gas City packs and formulas	`CURRENT_SOURCE` — `Architecture.md` §35-36

Prior architecture documents in this estate decayed because implementation names were written as architecture and then diverged from runtime. Do not prescribe implementation names as architecture. When a name changes, change this table; do not rewrite the capability boundary.

4. Product boundary¶

WHAT THIS IS¶

A Drupal content system the customer owns and operates.
A permissions-enforced boundary between what agents may do and what only an authorized human may do.
A repeatable editorial QA capability that produces specific findings.
Reproducible from its own repository, by composition of recipes and a site template.
Governed: the governance is part of the product, not an adjacent product.

WHAT THIS IS NOT¶

Not a second CMS. Agents get no independent content database, publication state, permissions model, workflow state or authoritative memory store. CURRENT_SOURCE — Architecture.md §1.
Not an agent orchestrator, and not Gas City. Gas City manufactures the product; Drupal runs it. CANONICAL_POLICY — Architecture.md §5.
Not a marketplace, and not a bundle catalogue.
Not a separate "Drupal Agent Governance" product. AMCS owns governance. CANONICAL_POLICY — operator direction, 2026-09-14.
Not bluefly.io. That site is a later reference consumer. CURRENT_SOURCE — Vision.md.
Not AMCS-CF-001. That packet is a certification/proof slice. CURRENT_SOURCE — Vision.md, Architecture.md §4.2.
Not one editorial workflow. The QA pipeline is a capability inside the product, not the product definition. CURRENT_SOURCE — Vision.md.
Not an AI site builder. CURRENT_SOURCE — governed-product-factory doc §14.

Runtime relationship¶

Reproduced from Architecture.md §1, which owns it. If the two ever differ, Architecture.md wins.

Human editors + governed agents
                │
                ▼
       Drupal interaction surfaces
       Canvas / UI / API / MCP
                │
                ▼
      Drupal identity + permissions
                │
                ▼
       Drupal entities + revisions
                │
                ▼
        Content Moderation
                │
        ┌───────┴────────┐
        │                │
        ▼                ▼
    FlowDrop            ECA
 multi-step work   bounded reactions
        │                │
        └───────┬────────┘
                ▼
        Drupal AI / Tools
                │
                ▼
      provider integrations

The system of record remains Drupal. Every arrow crosses an authority the customer already owns and already understands. That is the product.

5. Relationship to ContextControl¶

AMCS must work without ContextControl. ContextControl is a logical expansion, never a prerequisite. CANONICAL_POLICY — operator direction, 2026-09-14, consistent with Vision.md ("ContextControl: organizational learning product, separate from AMCS. Not the AMCS content model").

Question	AMCS	ContextControl
Scope	One customer's Drupal content operation	The broader agent operation across systems
Authority	Drupal entities, permissions, moderation	Organizational learning and context governance
Sold to	The organization that runs the site	The organization that runs many agents
Required for the other?	No	No

The expansion path is real but ordered: a customer operating AMCS successfully is a qualified ContextControl conversation. A customer who needs ContextControl before AMCS works has not bought AMCS.

A related boundary, recorded because it has already caused confusion in this estate: ai_context is Drupal's in-site AI context capability and is maturity-gated inside AMCS (CURRENT_SOURCE — Architecture.md §19). ContextControl is a separate commercial product. They are not the same thing and the names do not substitute for each other.

6. The buyer¶

Role	Description	Tag
Ideal customer	An organization that already runs Drupal as a real content operation, has an editorial process with review, and has a compliance, accessibility or public-obligation reason that publication cannot be automatic.	`CURRENT_SOURCE` — governed-product-factory doc §16 names bounded public-service operators as the strongest first vertical for exactly these reasons.
User	Editors, content authors and reviewers. They experience AMCS as their normal Drupal editing interface with a QA step and better findings.	`CANONICAL_POLICY` — the editor-can-own-the-page canary.
Champion	The person accountable for editorial throughput and quality — a content lead, digital services manager, or editorial director. They feel the QA backlog personally.	`NOT_ESTABLISHED` — no customer interview evidence exists in tracked source.
Economic buyer	The budget holder for the digital service: a director of digital, CIO, or agency principal.	`NOT_ESTABLISHED` — same.
Technical approver	Whoever owns the Drupal platform. They block anything that adds a second system to administer, and they are right to.	`CURRENT_SOURCE` — this is why §4's "not a second CMS" is a commercial requirement, not an aesthetic one.

Blockers¶

Blocker	Where it bites	Answer
"AI cannot touch our publish button."	Earliest objection, from the technical approver and often from legal.	This is the product, not an objection to it. The boundary is enforced by Drupal permissions, provable by attempting the transition as an agent identity. `CURRENT_SOURCE` — `Architecture.md` §32.
"We cannot send our content to a model vendor."	Procurement and data governance.	Provider selection is deployment configuration, not baked into the product. `CURRENT_SOURCE` — `Architecture.md` §10. Whether any specific deployment topology satisfies a given customer's data rules is `NOT_ESTABLISHED` per customer.
"We have been burned by an AI pilot."	The champion, privately.	The demo shape in §12 is designed to be falsifiable in front of them, including the failure path.
"Our Drupal is already a mess."	The technical approver.	Genuine. A site that cannot be rebuilt from its own repository is a precondition problem, addressed by the Readiness offer before anything else is sold. `CURRENT_SOURCE` — governed-product-factory doc §15.
"Who maintains this after you leave?"	Economic buyer.	Customer ownership plus tested handoff. `CURRENT_SOURCE` — governed-product-factory doc §17.
Procurement cycle length in public-sector buyers.	Deal timing.	`NOT_ESTABLISHED` — no closed deal exists to measure against.

7. Job to be done, and the real buying trigger¶

Job to be done: "Get more content through review, at consistent quality, without adding headcount and without anyone being able to say an unreviewed change reached the public site."

Note what is absent from that sentence: model quality, token cost, agent count, and the word "AI". Those are means.

The real buying trigger¶

The trigger is not "we want to use an LLM." Teams who say that are exploring, and exploring does not have a budget line.

The trigger is one of:

Trigger	Shape
A review bottleneck with a named cost	A backlog, a missed publication window, or a queue that grows faster than the team.
An incident	Something wrong reached the public site. Now review is a board-level topic.
An obligation with a date	An accessibility, records, or policy obligation that must be demonstrably met on a schedule.
A failed or frightening AI pilot	Someone already ran an agent with too much authority and it is now blocked entirely. AMCS is the way to unblock it safely.
A modernization already funded	The budget exists for the platform work; agent-assisted content is the reason it is worth doing now.

NOT_ESTABLISHED — this trigger list is derived from the obligation structure described in governed-product-factory doc §16 and from the product's own mechanism. It is not derived from customer interviews, and no interview record exists in tracked source. Treat it as a hypothesis to falsify in the first ten qualified conversations (see §18).

8. Competitive reality¶

8.0 What this section is, and what it is not¶

NO PRODUCT WAS TESTED. Every capability below is what a vendor says about itself, fetched from a primary vendor address on 2026-09-14. Zero trials, zero demos, zero hands-on. VERIFIED here means verified that the vendor says it — never verified that it works.

Tags used in this section only:

Tag	Meaning
`VERIFIED`	Fetched from the named primary source on the stated date; quoted or closely paraphrased.
`VENDOR_CLAIM`	The vendor's own marketing assertion, fetched and quoted. Not a capability test.
`NOT_ESTABLISHED`	Could not be read at the named address. Not evidence of absence.

Rules binding anyone editing this section: put a fetch date beside every competitor claim; never upgrade "announced" into "has"; never quote a third-party write-up as the vendor's own words. Marketing pages change without notice and most carry no publication date — re-fetch before any claim here goes in front of a buyer. Limitations are listed in §8.5 and are part of the section, not a footnote to it.

8.1 Agents in a CMS are table stakes — and the denominator is three¶

VERIFIED, 2026-09-14. Three of three vendors ship agents; two of three ship MCP; all three describe grounding, brand rules or context.

AMCS MUST NOT BE POSITIONED ON "WE HAVE AGENTS IN A CMS."

State the denominator honestly: this is three verified vendors in the DXP and marketing-suite population, not a market survey. "Table stakes" is a fair reading of these three and is not a surveyed claim.

The defensible sentence is not "we are behind" and not "we are first":

Everyone has declared this. The Drupal-native incumbent labels its own version experimental. Nobody is competing on assurance.

That last clause is the finding. Across six fetched vendor surfaces, no vendor claims positive controls, negative tests, or proof that a refusal fires. Every vendor expresses governance as review, approval, policy or grounding — all permissive structures with exceptions. A human-review queue is a gate that can be waved through. That is an empty category, commercially.

8.2 Acquia Source¶

Field	Value
Vendor / product	Acquia — Acquia Source (AI-era Drupal CMS + DAM + Web Governance)
Sources fetched 2026-09-14	`acquia.com/products/source` (200); `docs.acquia.com/acquia-source/acquia-source-mcp-server` (200)
Date on sources	`NOT_STATED` — neither page carries a publication or last-updated date
Availability	Product page states no availability status; presented as shipping. `VENDOR_CLAIM`

Claim	Evidence	Tag
Built on Drupal	"Built on Drupal, fully managed, zero maintenance"	`VENDOR_CLAIM`
Named agents	"Site Builder Agent, AI Writing Assistant, AI Web Governance Agent"; customers can "create their own specialized agents"	`VENDOR_CLAIM`
Human-in-the-loop	"Every AI action is queued for human review before reaching production." And: "This is not a configuration option — it is how the platform works."	`VENDOR_CLAIM`
Audit	"Batch approvals, audit trails, full revision history"	`VENDOR_CLAIM`
Permissions	"Manage AI agents, user roles, and permissions from a single control layer."	`VENDOR_CLAIM`
MCP server	Exposes content types, media types, vocabularies, text formats, entities, content-modelling resources and Drupal Canvas components/pages. Tools include `create_node`, `update_node`, `batch_create_nodes`, `create_content_type`, `add_field_to_content_type` — write tools, and the docs say they "Evolve the content model by creating content types and fields." OAuth flow required.	`VERIFIED` (`docs.acquia.com`)

The single most useful competitive fact in this section, and it is Acquia's own word in Acquia's own docs:

The Acquia Source MCP server is "an experimental feature within Source CMS and must be enabled per site." VERIFIED, docs.acquia.com, 2026-09-14.

Do not over-read it: experimental-and-shipping is still ahead of not-shipping.

Three corrections that must not be reintroduced. These were wrong in the material this section replaces:

MCP is not on acquia.com/products/source. It is nowhere on that page. Cite the docs address for any MCP assertion about Acquia. VERIFIED.
Do not write "granular permissions" and attribute it to Acquia. The page says only "from a single control layer" and describes no granularity, scoping, or per-agent least privilege. NOT_ESTABLISHED.
Content models are not discussed on the marketing page at all; that material is in the MCP docs.

Where it overlaps AMCS: same substrate (Drupal, Canvas, content types/fields/media/taxonomy), same primitive (MCP tools that mutate the content model), same headline governance promise, and the same phrase — Acquia already uses "a single control layer" on a public CMS product page.

Where it does not: "fully managed, zero maintenance" means the customer does not own the runtime. Audit trails record what happened; no source here describes an authority chain for why it was allowed, nor an absolute denied scope that a broader allow cannot override. Pricing: NOT_STATED on both pages.

8.3 Contentstack Agent OS¶

Field	Value
Vendor / product	Contentstack — Agent OS, inside Contentstack AXP ("Agentic Experience Platform")
Sources fetched 2026-09-14	`contentstack.com/platforms/agent-os` (200); `contentstack.com/docs/agent-os/agent-os-architecture` (200)
Date on sources	Marketing page `NOT_STATED`; architecture docs last updated 20 Feb 2026. `VERIFIED`
Availability	"Agent OS is now widely available" — the vendor's exact phrase, quoted and not upgraded to "generally available". `VERIFIED`

Claim	Evidence	Tag
Agents	"Design specialized agents... Define the job, set the guardrails, and let the agents run."	`VENDOR_CLAIM`
Automations	"Routing content, sending notifications, syncing data, kicking off downstream processes."	`VENDOR_CLAIM`
Grounding	"Agents grounded in your structured content, customer data and brand rules"	`VENDOR_CLAIM`
Governance triad	Docs: Observability, Auditability, Brand Control. Auditability is "Detailed logs for actions, content changes, API calls, and errors."	`VERIFIED` (docs)
MCP	"The Model Context Protocol (MCP) enables secure, standardized integration with Contentstack services and third-party systems."	`VERIFIED` (docs)

Two corrections that must not be reintroduced:

A permissions model is NOT_ESTABLISHED at any Contentstack address. Neither the marketing page nor the architecture doc describes permissions or RBAC for agents. Third-party coverage asserts "a single set of permissions, audit logs and brand and policy guardrails" — that sentence was not verified at a Contentstack address and must never be quoted as Contentstack's.
Contentstack does not say "control layer." It says "agentic backbone", "system of action", and "agentic experience platform". Quote what they say. VERIFIED.

Also: their "safety rules" appear as grounding and brand rules. Grounding is a quality control, not an authority control. Do not conflate them — nothing on these pages prevents an authorised-but-wrong action, only an off-brand one.

Where it does not overlap: proprietary SaaS with a closed content model. No customer ownership, no self-hosting. Pricing NOT_STATED on both pages.

8.4 Optimizely Agent Platform (formerly Opal)¶

The product has been renamed. Writing "Optimizely Opal" without that acknowledgement is quotably out of date. Optimizely's support site files it under "Agent Platform (previously Opal)", and optimizely.com/ai/ is titled Optimizely Agent Platform and does not use the word "Opal" at all. "Opal" persists as the assistant surface and as the billing unit ("Opal credits"). VERIFIED, 2026-09-14.

Field	Value
Sources fetched 2026-09-14	`optimizely.com/ai/` (200); support "Opal overview" (200, updated 13 Jul 2026); support "Opal credits" (200, updated 2 Sep 2026)
Availability	Shipping. Support article states "Available"; 50+ prebuilt agents; live billing docs with a usage dashboard. `VERIFIED`

Claim	Evidence	Tag
Orchestration	"Drag and drop agents into a workflow. Schedule triggers so agents can work autonomously."	`VERIFIED`
Agent library	"Use 50+ out-of-the-box agents... or build your own."	`VERIFIED`
MCP	"Connect to Salesforce, Conductor, Google Analytics, and more through pre-built integrations and MCP connectors."	`VERIFIED`
Context and memory	"Give your agents skills, brand guidelines, and compliance rules to work from. Memory builds over time."	`VERIFIED`
Retrieval	The page says "Knowledge integration". It does not say "RAG".	`VERIFIED` wording; the label "RAG" is `NOT_ESTABLISHED`
Governance	Neither page describes permissions, approval workflow, audit trail or human-in-the-loop review. An Agent Directory with "Opal Administrators and Agent Builders" roles implies some role model that was not verified.	`NOT_ESTABLISHED` — three pages of a large support site were read. Not absence.

Pricing — the best-evidenced commercial fact in the set. VERIFIED from Optimizely's own support site, 2026-09-14:

Consumption-based credits, NOT per-seat. Pooled across products.
Complexity bands   chat/basic 2 · XS 10 · S 30 · M 70 · L 130 · XL 200 credits
Worked examples    Email Creation 2 · Experiment Planning 10 · Blog Post 70
Free allowance     200 credits/month per instance, "ending on 12/31/2026"

See §13. The allowance has a stated end date — re-check this block if it is quoted after 31 December 2026.

Where it does not overlap: it is a marketing suite, not a CMS. It orchestrates across Optimizely One; it is not operating a customer-owned content model. Positioning against it as a CMS competitor overstates the overlap — it is an agent-orchestration competitor.

8.5 What this section does not establish¶

No product was tested. Every capability is a vendor assertion.
Contentstack "permissions" is NOT_ESTABLISHED at a Contentstack address. Third-party coverage only.
Optimizely governance is NOT_ESTABLISHED, not absent — three pages of a large support site were read.
"Table stakes" (§8.1) rests on a denominator of three verified vendors.
Acquia's availability status is NOT_STATED on its product page; only the MCP layer carries a documented status, and that status is "experimental".
Every page except the dated Contentstack and Optimizely ones carries no publication date.
Drupal.org project figures in §8.6 are as of 2026-09-14 and move continuously.
Optimizely's complimentary allowance expires 31 December 2026.
Vendor category vocabulary (§9) was sampled from six surfaces, not trademark-searched.
Any quote here should be re-fetched before it enters a document a buyer will read.

8.6 The competitor that is not a vendor¶

"We can assemble this ourselves from Drupal contrib."

This is the primary competitor. It must be answered head-on and honestly, because the pieces are real and a technical buyer verifies them in one search.

What Drupal actually ships today¶

VERIFIED from drupal.org project pages, fetched 2026-09-14. These figures move continuously; re-check before quoting.

Project	Release	Stable?	Security coverage	Installs
`ai`	1.4.8 stable (1.5.0-rc3 available)	Yes	Covered	18,527
`ai_agents`	1.3.5 stable (1.4.0-beta1 available)	Yes	Covered	10,093
`tool` (Tool API)	1.0.0-beta8	No stable release	Not covered — coverage applies to stable releases	1,240
`ai_context` (Context Control Center)	1.0.0-beta5	No stable release	Not covered — same reason	1,007

ai ships AI Core, AI Automators, AI Explorer, AI Observability, AI Search (semantic/vector), AI Agents, 95+ AI providers, vector DB providers, Context Control Center and AI Metering. ai_agents makes agents configuration entities — a title, a system prompt, and a chosen tool list at /admin/config/ai/agents — with Field Type, Content Type and Taxonomy agents out of the box, and states that "the only development needed is if there is not a tool for what your agent is trying to solve." ai_context offers context items "just like any other Drupal content, with drafts, approvals, scheduling, and version history." All VERIFIED, 2026-09-14.

A COMPETENT DRUPAL TEAM CAN ASSEMBLE AN AGENTIC CMS TODAY.
ANY CLAIM THAT DRUPAL LACKS AGENT CAPABILITY IS FALSE AND SELF-DEFEATING.

Say the opposite, because it is both true and better positioning: Bluefly builds on exactly this stack. That is why the product is composable and why the customer owns it.

The four seams — where AMCS actually lives¶

Two of the four load-bearing pieces have no stable release. Tool API is beta8 at 1,240 installs; Context Control Center is beta5 at 1,007. Both sit outside the Drupal security advisory policy until a stable is cut. Assembling on beta and carrying the upgrade churn is a real cost, paid in staff time, forever. VERIFIED, 2026-09-14.

This cuts at Bluefly too, and saying so is what makes the rest credible: Bluefly consumes the same betas. The differentiator is who absorbs the churn, not whether it exists.

The ECA 2.x/3.x fork is a live trap. ECA 3.1 requires Drupal ^11.3 || ^12 and PHP 8.3, moved label/modeller/version into third_party_settings.modeler_api, and extracted AI function calls into ai_integration_eca. A model authored for a 2.x site is correct for that site and wrong for the next one. A self-assembling customer discovers this on their second site. CURRENT_SOURCE — measured across three Bluefly rigs spanning the fork.
The ecosystem's silent failure modes are the actual product. Measured on live sites: cron runs as anonymous, so ECA entity saves are silently denied with no log; config/install under a recipe is prefix-filtered to <module>.*, so foreign-prefixed config is silently dropped; the service account switch returns early when unset, and every save then fails the access check identically. CURRENT_SOURCE — Bluefly runtime measurement.

Every one of those produces a system that imports cleanly, fires on schedule, and produces nothing, forever, with every component behaving exactly as designed. A customer assembling from contrib will hit these and will not know they have.

Nothing in contrib is an authority boundary. ai_context gives drafts and approvals. ai_agents gives a system prompt and a tool list. Neither is a denied scope, an issuer, an expiry, a revocation, or a proof that the denial fires. Drupal ships the mechanism; the authority model is not in the box.

The one-sentence answer¶

You can assemble it — we do, from the same contrib. What you cannot assemble is the assurance that it did what you think it did.

The self-assembly competitor is strongest for a customer building one site with a strong in-house Drupal team and no compliance obligation. That customer is not the ideal customer in §6 and should not be pursued. Conceding that costs nothing and buys the credibility to be believed about the customer who is.

9. Positioning¶

Category: Agent-Managed Content System.

Deliberately not "AI CMS". "AI CMS" invites comparison on model quality and generation features, which is a race against vendors with more capital and is not where the value is. "Agent-Managed Content System" puts the emphasis on management — which is the part the buyer is actually afraid of.

The coinage is a genuine asset, and the adjacent vocabulary is already taken¶

VERIFIED across six vendor surfaces fetched 2026-09-14 (see §8.0 for the method and §8.5 for its limits):

Microsoft     "The Control Plane for Agents"            — literal product page TITLE
IBM           "the agentic control plane in IBM watsonx Orchestrate"
                                                        — product page first sentence
Acquia        "a single control layer"                  — on a CMS product page
Contentstack  "agentic backbone" / "system of action"   — not "control layer"

Two consequences, and they point in opposite directions:

Control-plane language is taken, and taken by Microsoft and IBM. Bluefly cannot own it and should not try. Acquia is already using "control layer" on a CMS product page, which makes it a naming collision in our own category, not just an adjacent one. Use the phrase to say which category we are in if a buyer needs the orientation — never as the distinctive positioning.
"Agent-Managed Content System" is clean. No vendor fetched uses it or anything near it. Contentstack's nearest coinages are "agentic backbone" and "agentic experience platform"; Acquia has no category coinage at all. The whole category vocabulary is infrastructure-side — control plane, control tower, backbone, gateway, registry — while AMCS is content-side. That asymmetry is where the coinage has room, and it is the reason to keep using it consistently rather than drifting toward the vendors' words.

NOT_ESTABLISHED: this was sampled from six vendor surfaces, not trademark-searched. Treat it as a positioning observation, not a clearance.

Positioning line to own:

Put AI agents to work inside Drupal without giving them the publish button.

CANONICAL_POLICY — operator direction, 2026-09-14.

Positioning statement:

For organizations that run Drupal as a real editorial operation and cannot allow unreviewed content to reach the public, AMCS is an Agent-Managed Content System that lets AI agents do genuine content work — drafting, checking, classifying, flagging — inside Drupal's own permissions, revisions and approval workflow. Unlike AI tools that sit beside the CMS and hand back text, and unlike agent platforms that become a second system to administer, AMCS gives agents bounded authority inside the system the customer already owns, and gives the publication decision to a human by construction rather than by policy.

Differentiating principle:

The boundary is the feature. Competitors differentiate on what the agent can do. AMCS differentiates on what it provably cannot.

10. Core product experience¶

DRAFT
  │
  ▼
AGENT_QA ─────────────────────────────────┐
  │                                        │
  ▼                                        │
FLOWDROP / governed QA pipeline            │  entry guards:
  │   deterministic validation             │  correct bundle,
  │   optional governed AI analysis        │  correct state,
  ▼                                        │  revision not already processed
FINDINGS                                   │
  │                                        │
  ├── FAIL ──► NEEDS_REVISION ─────────────┘
  │
  └── PASS ──► HUMAN_REVIEW
                    │
                    ▼
          AUTHORIZED HUMAN PUBLISHER
                    │
                    ▼
                PUBLISHED

CURRENT_SOURCE — Architecture.md §12, §13, §30; Status.md "Next Milestone". The exact state labels are owned by recipe_amcs, not by this document.

The key moment is not the AI generating text¶

Generation is commoditised and the customer is not impressed by it. The moment that closes a deal is the one in the middle of that graph:

THE AGENT FINISHES ITS WORK, WRITES WHAT IT FOUND,
AND THE CONTENT GOES TO A HUMAN — BECAUSE IT CANNOT GO ANYWHERE ELSE.

Two properties make that moment credible rather than theatrical:

It is enforced, not instructed. The agent role does not hold the publish permission. Attempting the transition fails at Drupal's access layer. CURRENT_SOURCE — Architecture.md §12, §23.
It is provable in both directions. AGENT_CAN_PUBLISH=NO and AUTHORIZED_HUMAN_CAN_PUBLISH=YES are separate assertions, and the second is what stops the first from being satisfied by a broken system. CURRENT_SOURCE — Architecture.md §32.

A demo that only shows the agent succeeding has shown nothing. See §12.

11. MVP¶

ONE PAID CUSTOMER
ONE MEANINGFUL WORKFLOW
ONE PROTECTED PUBLICATION BOUNDARY

One paid customer. Not a pilot, not a design partner without money, not bluefly.io. Money is the signal; everything else is a hypothesis wearing a customer's clothes.
One meaningful workflow. A content type the customer actually publishes on a schedule, with a review step that currently costs them something. Not a demo article.
One protected publication boundary. Proven in both directions, by attempt, in the customer's own environment.

The engineering acceptance test is not the product proof¶

This must be stated plainly because the two are routinely conflated in this estate's own material.

	Establishes	Does not establish
Engineering acceptance test — failure path, success path, zero recursion, agent-cannot-publish, human-can-publish, clean install, second site from the same template. `CURRENT_SOURCE` — `Architecture.md` §31-34	That the mechanism works and is reproducible. `TECHNICAL PROOF`.	That anyone will pay for it.
Product proof — a paying customer whose editors use it, on their own content, and who renews.	That the product has a market.	That the mechanism is correct.

CANONICAL_POLICY. Passing the engineering acceptance test with zero customers is a successful engineering milestone and a failed product. Reporting it as product-market proof is the specific error this row exists to prevent.

12. MVP proof — four levels¶

Each level is independently falsifiable. A lower level passing does not imply a higher one.

Level	Question	Pass condition	Current state
1. Reproducibility	Can the product be built from source, twice, with no hand assembly?	Fresh checkout → install → apply foundation recipe → apply domain recipe → no manual repair. Then the site template independently. Then a second customer-shaped site. `CURRENT_SOURCE` — `Architecture.md` §33-34.	See §19. Not asserted here.
2. Governance	Can the agent reach publication by any path?	`FLOWDROP_EXECUTIONS=1` per qualifying revision, `RECURSION=0`, `AGENT_CAN_PUBLISH=NO` proven by attempt, `AUTHORIZED_HUMAN_CAN_PUBLISH=YES`, no API / Tool / Canvas bypass. `CURRENT_SOURCE` — `Architecture.md` §31-32; `Status.md` "Next Milestone".	See §19.
3. Value	Does the customer's editorial operation measurably improve?	Agreed with the customer before the engagement, measured against their own baseline: throughput, review time, or defects reaching publication.	`NOT_ESTABLISHED` — no customer baseline exists.
4. Commercial	Does the customer pay, and then renew?	A signed engagement, delivered, followed by a renewal decision made on the product rather than the relationship.	`NOT_ESTABLISHED`.

The demo shape: BEFORE and AFTER, side by side¶

The demo is not a feature tour. It is a comparison the buyer can falsify.

	BEFORE	AFTER
A submitted article with real problems	Goes into a review queue. Someone finds some of the problems, eventually, depending on who is reviewing and how busy they are.	Enters QA. Comes back with specific findings naming the failing requirements. Moderation state is `needs_revision`. It is not published.
A correct article	Same queue, same wait.	Passes QA, arrives at human review with the checks already done. A human publishes it.
The agent tries to publish	—	It cannot. Show the attempt failing.
"What did the AI do?"	Ask whoever ran it.	Drupal revisions and moderation history, in the customer's own admin interface.

Run the failure path first. A demo that opens with success looks like a generation demo, which is the category AMCS is deliberately not in. Opening with a refusal establishes the category in about fifteen seconds.

13. Pricing¶

THESE ARE PLANNING HYPOTHESES, NOT VALIDATED MARKET PRICES. No AMCS engagement has been priced, quoted, won or lost. NOT_ESTABLISHED, deliberately and without softening.

Do not invent a new price model¶

Price bands and price drivers already exist in governed-product-factory doc §§15 and 18 and are not restated here. That document defines six offers with planning ranges and seven price drivers. Reference it. Changing those numbers is a decision for the commercial owner named in §1 — who does not currently exist.

Two documents in products/AMCS/ that do state per-month prices — amcs-factory/amcs-starter-kit-pricing.md and amcs-factory/bluefly-agent-governance-kit-one-pager.md — are superseded and must not be quoted. See §20.

The pricing unit is NOT per-agent¶

CANONICAL_POLICY. Three reasons, in order of strength:

Per-agent pricing prices the wrong thing. It charges for Bluefly's implementation detail. A customer who consolidates four narrow agents into one broader one has improved their system and reduced their bill, which means the price signal is pointed backwards.
Per-agent pricing invites the failure the product exists to prevent. Every per-agent dollar is an argument for more agents with more authority. The product's entire value is bounded authority.
The customer does not experience agents. They experience content moving through review. CURRENT_SOURCE — §2's list of what the customer does not buy. An invoice line the buyer cannot map to an outcome is a renewal risk.

The same argument disqualifies per-token and per-model-call pricing. Compute and model consumption are an internal cost to meter and optimise, explicitly "not the primary customer value metric or invoice unit." CURRENT_SOURCE — governed-product-factory doc §18.

The one real market price signal¶

VERIFIED from Optimizely's own support site, fetched 2026-09-14. It is the only published, dated, specific price in the competitive set (§8), and it is the metered model AMCS is choosing against:

Consumption-based credits, pooled across products, NOT per-seat.
Complexity bands   chat/basic 2 · XS 10 · S 30 · M 70 · L 130 · XL 200 credits
Worked examples    Email Creation 2 · Experiment Planning 10 · Blog Post 70
Free allowance     200 credits/month per instance, "ending on 12/31/2026"

The commercial contrast is structural, not rhetorical: in a metered model every governance check, every retry and every review cycle is billable, per action, forever. A customer who runs QA twice because the first pass found something pays twice for doing the right thing. A customer-owned deployment has no meter, which means the price signal does not fight the product's own behaviour.

That contrast is worth stating to a buyer. What it is not is evidence that Bluefly's own bands are right — those remain NOT_ESTABLISHED. One competitor's published price is a data point about that competitor, not a market. Re-check this block after 31 December 2026, when the quoted allowance expires.

The unit that survives all three tests is the one already in the referenced offer table: the service — scope of journeys and workflows delivered, then a recurring assurance fee against the running system. Whether those specific bands are right is NOT_ESTABLISHED.

14. Go to market¶

READINESS ──► FOUNDATION ──► PROVE ──► MANAGED ASSURANCE ──► EXPAND

Stage	What happens	Exit condition
Readiness	Paid assessment. Inventory the content operation, the review process, the obligations, and whether the site is reproducible from its own repository. Produce a fixed implementation proposal.	A named service, named owners, measurable acceptance criteria, and a decision to proceed or not. A Readiness that always proceeds is not an assessment.
Foundation	Build the governed Drupal foundation and the AMCS domain capability for the named workflow.	Clean install from source, no hand assembly.
Prove	Run the engineering acceptance test and the customer's own value measurement, in their environment, on their content.	§12 levels 1 and 2 pass; level 3 has a measured baseline and a first reading.
Managed Assurance	Recurring: security and release management, regression, evidence, improvement capacity. This is the renewal surface.	A monthly report the customer reads rather than files.
Expand	A second workflow, department, or journey onto the maintained foundation.	The second one costs materially less than the first. If it does not, see §16.

This ladder is the same shape as the offer table in governed-product-factory doc §15 (Readiness → Lane Pilot → Foundation Operate → Expansion Pack), stated in stage terms rather than SKU terms. CURRENT_SOURCE. It is not a second, competing GTM model, and must not become one.

Sequencing rule: no Foundation without a paid Readiness. An unpaid assessment is a proposal, and proposals are where scope goes to die.

15. Activation, retention, expansion¶

Activation event:

The customer's own editor publishes content that an agent worked on, through the human review step, in production.

Not first install. Not first agent run. Not the demo. CANONICAL_POLICY — activation must be an event in the customer's operation, not in Bluefly's delivery. Every weaker definition lets a stalled engagement report as activated.

Retention loop:

CONTENT ENTERS QA
   → findings the editors trust
      → less rework, faster review
         → more content routed through it
            → more findings, on more content types
               → the QA capability becomes the editorial process

Retention fails at the first arrow. If findings are vague, editors route around the QA step, and everything downstream stops. CURRENT_SOURCE — Architecture.md §31: "A result such as 'QA failed' is insufficient."

The commercial retention surface is Managed Assurance: security, releases, regression and evidence against a running system the customer depends on. CURRENT_SOURCE — governed-product-factory doc §17.

Expansion path:

ONE WORKFLOW → MORE CONTENT TYPES → MORE DEPARTMENTS
             → MORE AGENT ROLES (still bounded)
             → a second site on the same foundation
             → ContextControl, only once the agent operation
               has outgrown one Drupal site

ContextControl is the last step and never the first. See §5.

16. Unit economics¶

COGS drivers¶

Driver	Why it costs	Direction it must move
Delivery engineering per engagement	The dominant cost. Building the foundation and domain capability.	Down, via reuse of the recipes and site template.
Per-customer configuration divergence	Every customer-specific deviation is maintained forever, by us, across upgrades.	Toward zero. This is the thesis.
Assurance labour	Security updates, release verification, regression, evidence, incident response.	Down per customer as the fleet shares a release train.
Support and incident response	Response commitments must be funded explicitly. `CURRENT_SOURCE` — governed-product-factory doc §18.	Flat per customer; must be priced, not absorbed.
Compute and model consumption	Real, metered, and internal.	Optimised internally. Not an invoice unit — see §13.
Upstream tracking	Keeping current with Drupal core and the contrib AI stack.	Fixed cost amortised across all customers — which is an argument for more customers on the same foundation, and against forks.

The economic test¶

Does each implementation make the next one cheaper?

If yes, this is a product and margin improves with every customer. If no, it is a consultancy with a documentation habit, and the offer table's margins do not hold.

IF EVERY CUSTOMER PRODUCES ANOTHER DRUPAL SNOWFLAKE,
THE PRODUCT THESIS HAS FAILED.

That failure is measurable and should be measured from customer two, not discovered at customer five:

Measure	Healthy	Failing
Delivery effort, customer N vs N-1	Declining	Flat or rising
Configuration that lives in the shared recipes vs. per-customer	Shifting toward shared	Accumulating per-customer
Customer-specific forks of a shared recipe	Zero	Any, unresolved
Time to apply an upstream security update across the fleet	Roughly constant as the fleet grows	Scaling with customer count

The second measure is the leading indicator. A per-customer deviation is cheaper to refuse than to carry, and the moment to refuse it is during Readiness. CURRENT_SOURCE — governed-product-factory doc §17: reusable packs and recipes "lower Bluefly delivery cost while improving the customer's upgrade position."

17. North-star metric¶

Verified Agent-Managed Changes¶

A content change that an agent materially contributed to, that passed the governed QA pipeline, and that an authorized human published — counted in production, in customer environments.

All four qualifiers are load-bearing. Drop any one and the metric becomes gameable:

Qualifier	What dropping it would permit
Agent materially contributed	Counting ordinary human edits that happened to pass through the pipeline.
Passed the governed QA pipeline	Counting agent output that bypassed QA entirely.
An authorized human published	Counting drafts, which cost the customer nothing and prove nothing.
In production, in customer environments	Counting Bluefly's own demo traffic, which is the cheapest number in the world to manufacture.

It is a north star because it can only increase when the mechanism works, the customer trusts it, and they are actually using it. A number that requires all three to move is worth more than three numbers that each move on their own.

Supporting metrics¶

Metric	What it protects
Findings acted on / findings produced	Finding quality. A high production rate with a low action rate means editors have started ignoring it — the retention failure in §15.
QA executions per qualifying revision	Must be exactly 1. Anything else is the recursion defect. `CURRENT_SOURCE` — `Architecture.md` §14.
Agent publication attempts blocked	The boundary is live and exercised. Zero over a long period means the boundary is untested, not that it is safe.
Human review time per change	The customer's own before/after value measure.
Delivery effort, customer N vs N-1	The §16 economic test.
Per-customer configuration divergence	The leading indicator of thesis failure.
Custom code added / avoided / upstreamed / deleted	Makes net-negative ownership economically visible. `CURRENT_SOURCE` — governed-product-factory doc §20.
Time to apply an upstream security update across the fleet	Whether the fleet is a fleet or a collection.

Deliberately not metrics: agents deployed, agent runs, tokens consumed, model calls. They measure activity, not outcome, and they are the exact metrics §13 refuses to price on.

18. Kill criteria¶

Stated in advance, because criteria written after the fact are rationalisations.

#	Kill / pivot criterion	Why it is fatal
1	The ten-qualified-conversation test. Ten conversations with buyers matching §6, and the boundary is not the thing they respond to.	The entire positioning in §9 rests on the boundary being the felt need. If it is not, the product is an AI content tool competing on generation, which is a category we should not enter.
2	No paying customer for the narrow vertical after the engineering acceptance test passes.	The mechanism works and nobody wants it. This is the cleanest possible kill signal and must not be explained away as a sales problem without evidence that it is one.
3	Customer N costs the same as customer N-1, twice in a row.	The §16 economic test has failed. It is a consultancy. Either fix the composition or price it as services.
4	The publication boundary is bypassable by a path we did not close.	The product is the boundary. A bypass is not a bug to patch quietly; it is a product-integrity event.
5	Editors route around the QA step.	Findings are not good enough to be worth the friction. Fix findings or stop.
6	Upstream ships the governed agent/publication boundary in Drupal core or a maintained contrib module.	Then we should adopt and contribute, not compete. `CURRENT_SOURCE` — the estate's standing contribution-first doctrine. This is a good outcome mistaken for a bad one; it kills the differentiator, not the customer relationship.
7	Delivery requires a per-customer fork of a shared recipe that cannot be folded back.	The upgrade position — a core customer promise — is gone.

The ten-qualified-conversation test, stated precisely¶

A conversation counts only if the person matches the §6 ideal customer and the economic buyer or champion is in it. Ten conversations with interested engineers is not the test; it is the thing that feels like the test.

Record for each: the trigger they named (against §7's list), whether the boundary landed, what they asked about price, and what they said was blocking them. Ten of those is enough to falsify §7, §9 and §13 — which is the point.

19. Evidence state¶

19.0 The headline, unrounded¶

RUNTIME-VERIFIED       = 0      no live system was observed for either product
NOT_ESTABLISHED_CLAIMS = 13 of 37 claims (35%)   AMCS 4 + ContextControl 9
OPEN_PROBES            = 19     items needing a probe before they can be closed
REFUTED                = 5      false as stated

NOT_ESTABLISHED_CLAIMS and OPEN_PROBES are two different metrics and must never be merged into one number.

NOT_ESTABLISHED_CLAIMS   claims whose adjudicated STATE is NOT_ESTABLISHED.
                         Counted from the state column. 13.

OPEN_PROBES              items that still need a probe run against them. 19.
                         A superset: it also includes defects, and rows tagged
                         CURRENT_PRODUCT_DIRECTION, HISTORICAL/SUPERSEDED or
                         TOOLING_BLOCKED — none of which is NOT_ESTABLISHED.

Both are legitimate under their own definitions and both belong here. Reporting 19 as the NOT_ESTABLISHED count overstates the unproven set by six and silently reclassifies a blocked probe, a superseded artefact and a defined-but- unrun acceptance test as unproven claims. They are not the same condition and they do not have the same remedy.

A high unproven count is the point of this table, not an embarrassment in it. It is what an honest adjudication of a prototype/MVP-stage product produces. Rounding it down, or restating it as "partially verified", would destroy the only thing the table is for.

RUNTIME-VERIFIED = 0 is the single largest finding in this document. Every positive claim below rests on repository-tier evidence — what tracked source says — and repository-tier evidence cannot establish runtime-tier state. See §12: reproducibility and governance are not proven by a document that describes them.

Adjudication refs, all fetched 2026-09-14:

Repository	Ref	SHA
`blueflyio/blu/blucity-docs`	`origin/release/v0.1.x`	`f6a2da1a`
`.../site-templates/amcs/site_template_amcs`	`origin/release/v0.1.x`	`a3decc0c`
`.../site-templates/amcs/amcs-demo`	`origin/release/v0.1.x`	`2239eed6`

19.1 How to read this table¶

CURRENT STATE carries only states received from the adjudication. Nothing here is inferred by this document. Every CURRENT_SOURCE cites a ref and path; every NOT_ESTABLISHED names the probe that would establish it — an executable next action, not a wish. No [x] appears anywhere.

REFUTED means the claim is false as stated. It does not mean the named component is absent or unwanted — read the row.

19.2 AMCS claim adjudication — 17 of 17¶

COMPONENT	EXPECTED AUTHORITY	CURRENT STATE	EVIDENCE	REQUIRED WORK
The name "Agent-Managed Content System"	The installable product's own metadata	`CURRENT_SOURCE`	`amcs@a3decc0c:composer.json` description and `recipe.yml:1` — "AMCS — Agent-Managed Content System". Tracked string is hyphenated.	None at this tier.
Drupal remains the system of record	`Architecture.md`	`CANONICAL_POLICY`	`blucity-docs@f6a2da1a:products/AMCS/Architecture.md:104` — "The system of record remains Drupal." Restated at `:911`.	None at this tier.
Agents cannot replace Drupal authority	Drupal permissions / workflow transition access	`CANONICAL_POLICY`	Same file `:329`, `:451` — publication "is enforced technically. It is not prompt policy." `:568` states the required proof `AGENT_CAN_PUBLISH=NO`.	Runtime proof by attempt. Policy is stated; enforcement is unobserved.
FlowDrop owns the primary runtime QA graph	`Architecture.md` §13 + exported site config	`CANONICAL_POLICY` + `CURRENT_SOURCE` — with a version contradiction, §19.3	Policy at `Architecture.md:333`, `:365`. Source: `amcs-demo@2239eed6:config/sync/flowdrop_workflow.flowdrop_workflow.amcs_article_qa.yml`, 2,656 lines, `status: true`; 14 flowdrop modules enabled in `core.extension.yml`.	Settle the version disagreement before quoting `^2.5`.
Gas City manufactures but does not run editorial workflows	`Status.md`, `Architecture.md` §37	`CANONICAL_POLICY`	`Status.md:54` — "Private manufacture. Not the site's editorial workflow." `Architecture.md` §37 titled "FlowDrop ≠ Gas City Formula".	None at this tier.
Composition chain foundation → domain → product	`composer.json` / `composer.lock` of the site template	`CURRENT_SOURCE` for the resolved graph — but the direct require is `recipe_drupaltown`	`amcs@a3decc0c:composer.lock` — `recipe_amcs` requires `recipe_blucity ^0.1.1`, both present. `amcs@a3decc0c:composer.json` requires `blueflyio/recipe_drupaltown` and `recipe_amcs`, not `recipe_blucity`. Lock shows `recipe_drupaltown` and `recipe_blucity` with byte-identical require blocks — one foundation recipe installed twice under two names.	Resolve the duplicate foundation. See §19.3 defect 1.
An architecture document exists	`products/AMCS/Architecture.md`	`CURRENT_SOURCE` — a document, not runtime	932 lines, `status: canonical`. Its own front matter declares `code_reviewed: false`, `production_verified: false`. `Status.md:36` — "Do not treat architecture prose as runtime proof."	Nothing at this tier; see the rows below for the runtime tier.
Implementation exists partially	Site template + demo site config	`CURRENT_SOURCE`	`amcs@a3decc0c:composer.lock` resolves 134 packages; `amcs-demo@2239eed6:config/sync/` carries the exported site config including the QA graph. `Status.md:37` — "Release composition exists; empty-DDEV two-run behavioral proof is not closed."	The two-run proof.
Clean install + two-run acceptance	Runtime execution records from an empty DDEV	`NOT_ESTABLISHED` — and on the current ref it cannot currently succeed, see §19.3 defect 2	`Status.md:41` unchecked; `:79` — "still unexecuted as a closed receipt." No receipt artefact found.	Fix `recipe.yml` vs `composer.json` first, regenerate the lock, then: empty DDEV → apply the template → capture the `drush recipe` exit code and the `core.extension.yml` diff → run the vertical twice on the same revision → assert one execution per qualifying revision, zero recursion. A green exit code is not the proof; the effect is the second run not re-firing.
Production verification	A named production host	`NOT_ESTABLISHED`	`Status.md:42` unchecked; `Architecture.md` front matter `production_verified: false`. No runtime observation taken.	Name the host. Probe with `--silent --show-error --fail-with-body --write-out '%{http_code}'` and validate an application-specific body marker, not the status code — a proxy 502 body arrives as HTTP 200 on these zones. Then `drush status` and `drush config:status` from inside the container.
Customer #2 portability	A second site from the same template	`CURRENT_PRODUCT_DIRECTION` — a defined acceptance test, not performed	`Architecture.md:591`; `Roadmap.md:75` deliverable D2; `Status.md:95-96` — the test comes after the Launch Factory path exists.	Instantiate a second independently named site from the same ref with zero Bluefly-specific config copies; diff its `config/sync` against the first and assert the only differences are site identity. `bluefly.io` does not count.
Paid AMCS pilot demand	An owning financial system	`NOT_ESTABLISHED`, with counter-evidence	`amcs-90-day-product-roadmap.yml:16` lists "1 paid pilot" as a target, in a file headed `Status: DRAFT`, dated 2026-05-21. Counter-evidence: `amcs-phase1-gascity-beads.yaml:263` lists under `can_fake:` → "Paid pilot client data (use sample webpages)". A demo plan that authorises fabricating pilot client data is evidence that none existed.	A signed agreement, invoice or paid-pilot record from an owning system, named and dated.
Market-validated pricing	Win/loss or willingness-to-pay data	`NOT_ESTABLISHED`	The only pricing artefact anywhere under `products/` is `Status: DRAFT — pending launch` and self-labels its prices "DRAFT sales copy, not verified facts". Positive control: the `pricing` grep returns 6 files in `products/AMCS/`, 0 elsewhere. No customer, transaction, quote or willingness-to-pay evidence located.	Documented win/loss or willingness-to-pay data from at least three qualified prospects against a specific tier. See §18's ten-conversation test.
The per-month subscription tiers	—	`HISTORICAL / SUPERSEDED` as authority; live-looking as an artefact	See §20. The banner is correctly placed but narrowly scoped.	Not to be established — to be withdrawn or re-scoped. See §20.
Cedar / ContractPlane are required for AMCS	—	`REFUTED` — they are an optional additional external/ABAC layer	`Architecture.md:467` — Cedar "may be used as an additional external/ABAC policy layer when a concrete requirement requires it… Do not make Cedar a prerequisite for basic Drupal authorization." `Status.md:69` — "not the default AMCS proof ledger." Measured: `cedar` = 0 and `contractplane` = 0 in `amcs-demo@2239eed6:config/sync/core.extension.yml` (76 modules enabled).	None. The refutation is the finding. Do not reintroduce either as a prerequisite.
MCP is required for AMCS	—	`REFUTED` — MCP is an edge protocol, maturity-gated	`Architecture.md:428` — "MCP is an edge protocol. It does not own business logic… Use it only when external agents actually require governed Drupal Tool access." `:435` — "If the product does not require external MCP access, it does not need MCP merely because MCP exists." Measured: `mcp` = 0 in the demo's `core.extension.yml`.	None.
OSSA / DUADP are required for the AMCS MVP	—	`REFUTED` as a doctrinal prerequisite — they are later interoperability. Read the nuance.	`Architecture.md:473` — "OSSA/DUADP may remain Bluefly interoperability protocols… They are not Drupal's content authority." `:480` — "The manifest describes the agent. It does not grant itself permissions." `Status.md` front matter explicitly supersedes the status that treated them as MVP prerequisites. Nuance: `duadp` = 0 at both layers, but `ai_agents_ossa` is enabled in the demo and `recipe_amcs` hard-requires `drupal/ai_agents_ossa` in the lock.	None. But "not required for the MVP" and "not present" are different claims and must not be collapsed — OSSA is present as a recipe domain dependency; DUADP is absent at both layers.

Positive control for the three refutations. A single grep -c -i sweep over amcs-demo@2239eed6:config/sync/core.extension.yml (83 lines, complete file, no pager, no head) returned in one pass:

cedar = 0   contractplane = 0   mcp = 0   duadp = 0   kagent = 0   kb_cache = 0
ossa  = 1   ai_context = 1      flowdrop = 14          <- POSITIVE CONTROL: PROBE FIRES
OUTPUT_COMPLETE=YES   TRUNCATED=NO   POSITIVE_CONTROL=PASS   DENOMINATOR=76 modules

Three absences scored from a probe that demonstrably fires on the same file, in the same pass. Without the ossa/flowdrop hits the zeros would be an unread instrument rather than a finding.

19.3 Defects found while adjudicating — recorded here, fixed elsewhere¶

Four defects in canonical AMCS documents and in the delivery ref. None is fixed by this file, because none of these documents is owned by it. They are recorded so the finding is not lost between lanes.

1. Status.md inverts release and main, and is one commit stale. Status.md (canonical) dismisses recipe_drupaltown as "local/default-branch drift" on main. Measured on freshly fetched refs: release requires it; main does not. Cause established rather than guessed — Status.md describes tip 1b4be8bb (2026-09-10) accurately and was overtaken by ad8f58d the next day, which renamed the vendor prefix and swapped recipe_blucity for recipe_drupaltown. The document is not careless; it is one commit stale, and its staleness is expressed as a confident dismissal of the true state. That is the dangerous form: a correct observation promoted into a rule that now suppresses the real finding. Owner: Status.md.

2. site_template_amcs cannot apply cleanly on the current release ref. amcs@a3decc0c:recipe.yml does install: agentic_canvas and sets it as the default theme; agentic_canvas is absent from composer.lock — dropped by ad8f58d, with recipe.yml never updated. It appears in exactly one tracked file in that repository. Corroborating: the demo site's exported theme is Olivero, consistent with the template's theme action never having applied. So the clean-install row above is not merely "unrun" — on the current delivery ref it cannot succeed. Owner: site_template_amcs.

3. FlowDrop — a three-way disagreement across three tracked sources.

Architecture.md:133   drupal/flowdrop ^2.5, "Stable / security-covered"
Status.md:70          "Release composer.json already requires ^2.5 … Close the
                       issue with that proof. Do not re-bump."
amcs@a3decc0c:composer.lock   recipe_amcs requires "^1.6"; resolves to 1.6.1

The graph the site template actually installs is FlowDrop 1.6.1. The lock pins recipe_amcs at an older ref than the HEAD Status.md cites, so both can be true and the delivered artefact is 1.6.x regardless. Probe: read recipe_amcs origin/release/v0.1.x:composer.json and compare to the ref pinned in the lock; if ^2.5 is at HEAD, regenerate the lock and re-verify resolution before closing the issue with "that proof".

4. Cedar's authorization policy type exists with zero authorization policies. Measured in the ContextControl repository: 4 policy types (authorization, compliance, dev_standard, quality_gate) and exactly 2 actual policies, both dev_policy source-hygiene rules (no_eval, no_hardcoded_keys). The authorization type is empty. Relevant to any claim that Cedar governs AMCS — and it is another instance of the estate's signature shape: the model is right, and nothing populates it. Owner: cedar-policies / ContextControl.

19.4 What this table does not cover¶

No runtime tier at all. No live AMCS system was reachable or probed. Every state above is repository-tier.
Component-level rows that were never adjudicated. The AMCS field contract, moderation states and transitions, QA entry guards and the recursion guard, agent role definitions, the human publisher role, provider abstraction in use, and absence of secrets from the recipe and template were not individually adjudicated and carry no state here. They are not NOT_ESTABLISHED by measurement; they were outside the adjudication scope, which is a different thing and must not be reported as the first.
Counting caveat, stated because the arithmetic does not partition. The adjudication's category totals sum to 43 across 37 claims, because several claims carry two states (policy and source). No category total may be read as a breakdown of 37, and subtracting them will not reconcile.
The AMCS half of both metrics, for anyone quoting this section alone: NOT_ESTABLISHED_CLAIMS = 4 (clean install, production verification, paid pilot demand, market-validated pricing) and OPEN_PROBES = 8 — the four above plus Customer #2 portability (CURRENT_PRODUCT_DIRECTION), the pricing tiers (HISTORICAL / SUPERSEDED), and two of the §19.3 defects. Quote the metric with its label; a bare number from this section is ambiguous by construction.

20. The resulting Bluefly portfolio¶

                        BLUEFLY

   ┌──────────────────────────────────────────────────────────┐
   │  WHAT THE CUSTOMER OPERATES                              │
   │                                                          │
   │     AMCS                          ContextControl         │
   │     Agent-Managed Content         governed agent         │
   │     System — one customer's       operation across       │
   │     Drupal content operation      many systems           │
   │                                                          │
   │     neither requires the other                           │
   └──────────────────────────────────────────────────────────┘
                              ▲
                              │  manufactured by
                              │
   ┌──────────────────────────────────────────────────────────┐
   │  HOW BLUEFLY MANUFACTURES IT — never sold, never          │
   │  the customer's runtime                                   │
   │                                                          │
   │     Site Factory / Gas City · Beads · packs ·            │
   │     formulas · orders · GitLab CI                        │
   └──────────────────────────────────────────────────────────┘
                              ▲
                              │  built on
                              │
   ┌──────────────────────────────────────────────────────────┐
   │  UPSTREAM — not ours, not sold, not forked                │
   │                                                          │
   │     Drupal CMS · Drupal core · Drupal AI · AI Agents ·   │
   │     FlowDrop · ECA · Canvas · Search API                 │
   └──────────────────────────────────────────────────────────┘

   ┌──────────────────────────────────────────────────────────┐
   │  MOAT / INTEROPERABILITY — later, never a prerequisite    │
   │                                                          │
   │     OSSA · DUADP · ContractPlane · Cedar                 │
   └──────────────────────────────────────────────────────────┘

CANONICAL_POLICY for the layer boundaries (operator direction, 2026-09-14; Architecture.md §5; platform-glossary Commercial Model). The membership of the bottom two boxes is CURRENT_SOURCE and expected to change — see §3.1.

Classification of existing `products/AMCS/` material¶

All 20 files tracked on release/v0.1.x as of 2026-09-14, read in full.

File	Classification	Basis
`Architecture.md`	`CANONICAL`	Technical authority. Replacement 2026-09-02. Not superseded by this file.
`Vision.md`	`CANONICAL`	Product thesis. Consistent with this file.
`Status.md`	`CANONICAL`	Observed maturity.
`Roadmap.md`	`CANONICAL`	Delivery sequence.
`Product-Definition.md` (this file)	`CANONICAL`	Commercial definition.
`bluefly-governed-product-factory-gas-city-official-docs-update-2026-08-03.md`	`CANONICAL` (§§14-18 and §§22-23), `HISTORICAL` elsewhere	The only tracked source for commercial packaging and pricing logic. Carries no supersession banner. See the contradiction note below.
`AMCS-CF-001.execution-packet.yml`	`HISTORICAL`	Certification/proof slice. Explicitly "does not define the AMCS product" (`Architecture.md` §4.2). References absolute workstation volume paths that are not portable.
`_archive/Bluefly_Governed_Product_Factory_..._2026-08-03.docx`	`HISTORICAL`	Binary source of the markdown twin above. Correctly filed under `_archive/`.
`amcs-factory/amcs-starter-kit-pricing.md`	`SUPERSEDED`	Declares itself superseded 2026-08-03 in a correctly placed banner whose scope is too narrow — it disclaims prices, SOC 2 and EU AI Act language, leaving three architectural claims certified by omission. See contradiction 2 below.
`amcs-factory/bluefly-agent-governance-kit-one-pager.md`	`SUPERSEDED`	Declares itself superseded 2026-08-03. Describes a separate "Agent Governance Kit" product that does not exist — AMCS owns governance.
`amcs-factory/amcs-phase1-demo-runbook.md`	`HISTORICAL`	Phase 1 OSSA/Cedar/ContractPlane demo. The referenced copy.
`amcs-factory/amcs-phase1-demo.runbook.md`	`DUPLICATE`	Byte-identical to the file above and referenced by nothing. Removed in the same change as this file.
`amcs-factory/amcs-demo-script-governed-agent-that-remembers.md`	`HISTORICAL`	Superseded banner present. Kagent/LiteLLM framing is not the canonical runtime.
`amcs-factory/acquia-pilot-demo.runbook.md`	`HISTORICAL`	Superseded banner present.
`amcs-factory/contextcontrol-mvp-launch.runbook.md`	`MISFILED`	ContextControl launch plan filed under AMCS. ContextControl is a separate product with its own directory. Its own banner says so.
`amcs-factory/amcs-90-day-product-roadmap.yml`	`SUPERSEDED`	States "Primary Product: ContextControl MemoryPlane". Contradicts both this file and `Roadmap.md`.
`amcs-factory/amcs-phase1-gascity-beads.yaml`	`SUPERSEDED`	Superseded banner present; names a retired write target.
`amcs-factory/memory-evidence-event-types.yaml`	`HISTORICAL`	ContractPlane memory evidence schema, DRAFT. Belongs to ContractPlane, not AMCS.
`amcs-factory/ossa-memory-contract-schema.json`	`MISFILED`	OSSA schema extension. Authority is `blueflyio/ossa/openstandardagents` per `AUTHORITY-MATRIX.md`.
`amcs-factory/examples/accessibility-reviewer-memory.json`	`MISFILED`	Example for the OSSA schema above. Same owner.
`amcs-factory/Repo Ecosystem Comparison.txt`	`SUPERSEDED` — and it is the live bait in this directory	Asserts a company-level thesis incompatible with AMCS being the product: Bluefly "is not a DXP or a runtime; it is the governance, discovery and evidence layer above all runtimes and DXPs", monetised through a 15% marketplace commission, $1K-per-level certification fees, per-event evidence pricing and a ~$50K sovereign-kit licence. It carries no supersession marker of any kind — unlike every other stale file here — so a reader encounters a confident, complete, unqualified strategy with nothing telling them it is dead. That is the reuse hazard, and it is the reason for the `SUPERSEDED` classification rather than `HISTORICAL`.

Nothing in the SUPERSEDED, HISTORICAL or MISFILED rows may be quoted to a customer, used to price an engagement, or cited as current architecture. MISFILED rows should move to their owning product directory in separate, single-purpose changes — not folded into this one.

Contradictions found in existing material¶

Recorded because they are findings, not inconveniences.

Two incompatible commercial models are both tracked under products/AMCS/. amcs-starter-kit-pricing.md sells per-month subscription tiers for an agent-governance kit; governed-product-factory doc §15 sells fixed-fee modernization engagements plus a monthly operate retainer. The first is self-declared superseded; the second is not. This file resolves the conflict in favour of the second and records the first as dead. CURRENT_SOURCE.
The pricing file's defect is the SCOPE of its disclaimer, not its placement — and that is worse. The banner sits at line 9, above every price table; a reader cannot reach the per-month tiers without passing it. On placement the document is well constructed and that should be said plainly. But the banner disclaims exactly three things — prices, "SOC 2 Type II", and EU AI Act urgency language — and nothing else. Three architectural claims sit outside it, presented as product fact:

Claim, un-disclaimered	Current canonical source
`composer require bluefly/amcs-starter` — "one command install"	No such package in any composer graph read. The installable artefact is `blueflyio/site_template_amcs`, and `Status.md:79` notes it is a recipe/site template, not a `composer create-project` project-template. The advertised command does not describe the shipped artefact.
"Kagent Runtime Adapter — Deploy OSSA agents to Kubernetes via Kagent CRDs"	`Status.md:62` — "Kagent is not the AMCS runtime."
"Revenue anchor is ContractPlane"	`Status.md:69` — "Not the default AMCS proof ledger." Measured: `contractplane` = 0 modules enabled in the demo.

A READER WHO OBEYS THE BANNER EXACTLY STILL LEAVES BELIEVING
KAGENT IS THE AMCS RUNTIME AND CONTRACTPLANE IS THE REVENUE ANCHOR.

A disclaimer that scopes itself narrowly is more dangerous than a missing one, because it certifies everything it does not name. A reader who sees no banner is on guard; a reader who sees a specific, honest, well-placed banner reasonably concludes that what it omits was checked. CURRENT_SOURCE.

This supersedes two earlier framings of this file in this lane: it is neither "live bait" (the placement is right) nor "stale material correctly marked" (the scope is not). Required work: widen the banner to cover the OSSA / Cedar / ContractPlane / Kagent / MemoryPlane stack assumptions, or delete the rows carrying them — and set updated_at when doing so, since the file's own governance rule has not fired for the supersession edit (updated_at still equals created_at).

A third product thesis is tracked with no banner at all. amcs-factory/Repo Ecosystem Comparison.txt states Bluefly "is not a DXP or a runtime; it is the governance, discovery and evidence layer above all runtimes and DXPs," with marketplace commissions, certification fees and per-event evidence pricing. That is incompatible with AMCS being the product. It is the only file in the directory asserting a company-level thesis without a supersession marker. CURRENT_SOURCE.
products/Site-Factory/ does not exist on release/v0.1.x. Zero tracked paths. Architecture.md (replacement notice) and Status.md both cite products/Site-Factory/BlueflyAgents.com/01-BLUEFLY-CMS-REBUILD.md and products/Site-Factory/architecture/bluefly-cms-architecture/ as historical inputs; neither path is in the repository. AUTHORITY-MATRIX.md also lists "Site Factory" as a product with canonical Vision.md / Architecture.md / Roadmap.md, none of which exist. CURRENT_SOURCE, verified against origin/release/v0.1.x with a positive control. Two canonical documents cite absent paths, and the authority matrix names a product directory with no content. Routing note: correcting those citations belongs to the owners of Architecture.md, Status.md and AUTHORITY-MATRIX.md, not to this file.
"AMCS is the product" versus "AMCS is the demonstration." The Founder-locked Commercial Model (platform-glossary, 2026-08-24, CANONICAL_POLICY) states the commercial motion is governed modernization outcomes, and that the immediate product proof is "the Bluefly Drupal Launch Factory, demonstrated through AMCS." Vision.md and Roadmap.md follow that framing: AMCS is the vertical that proves the Launch Factory. Operator direction of 2026-09-14 elevates AMCS itself to the commercial product the customer operates, with Site Factory / Gas City as manufacture.

These are reconcilable in offer terms — the GTM ladder in §14 is the same ladder as governed-product-factory doc §15 — but they are not reconcilable in naming terms: one sells "modernization of your digital service", the other sells "an Agent-Managed Content System". The buyer, category and competitive set differ.

STATUS = UNRESOLVED_DECISION · OPERATOR_RULING_REQUIRED · opened 2026-09-14

This file is written to the 2026-09-14 direction, as instructed. The prior framing is recorded here rather than silently overwritten, because the Founder-locked entry is CANONICAL_POLICY and only the same authority can retire it.

Neither side is softened into agreeing with the other, and no commercial answer is invented here. Until the ruling is made, a reader should treat this document as the definition of AMCS-as-product and should know that a canonical entry of equal standing describes AMCS as the demonstration of a modernization motion. Both are live. A reader who takes only one of them has taken half the record.

No accountable product or commercial owner exists. Resolved as far as tracked source allows and then rendered as explicit operator decision slots in §1.1 — not left floating as NOT_ESTABLISHED, because no measurement will ever discharge it. Portfolio-Registry.yaml carries the AMCS slots with roadmap: null, pricing: null, customers: null; AMCS appears zero times in all three governance ownership matrices (positive control passed). Every pricing and packaging statement in this file is therefore a planning hypothesis nobody is currently empowered to ratify. It remains the single largest gap in this definition.