The governed factory operating model
This is the integration design for S4U 4.0: a business-intent workspace, an engineering method, and replaceable delivery adapters. It defines responsibilities and acceptance obligations; it does not claim that the future workspace, adapters or approval service are already implemented. The accompanying Business Intent Lifecycle explains the collaboration experience. The factory research sets out precedents and evidence limitations.
An AI-assisted factory can build conventional applications, agentic applications, or both. Automation of development and autonomy of the delivered application are separate design decisions. “Type 3” is an ambition used in some conversations, not a certification or a standard maturity level.
One workspace, explicit authorities
One interface should make collaboration simpler; it must not create competing masters for the same decision. Each fact has an authoritative owner and revision. Existing identity, repository, glossary or enterprise records can remain authoritative through adapters. A search answer, meeting summary or generated documentation page is a view of those records, not a new approval.
| Record | Accountable authority | What AI may do |
|---|---|---|
| Recording, transcript, source observation | Authorized contributor and applicable data policy | Extract proposed statements with source locations and uncertainty |
| Shared interpretation and stakeholder question | Business analyst | Draft, reconcile and visualize; BA reviews before sharing |
| Business rule, terminology and acceptance example | Designated domain owner | Propose alternatives and impact; never approve for the owner |
| Architecture and integration contract | Authorized technical owner, with business approval for changed meaning | Explore designs and produce evidence |
| Implementation and test result | Delivery team and identified verifier | Execute within a mandate; report limitations |
| Release and behavioural activation | Explicitly designated release/policy authority | Prepare an evidence package; act only within a valid grant |
Binding organizational constraints and approved project authority take precedence. Applicable normative controls come next; an exception is valid only where those controls permit an authorized, scoped exception. Operating cards, skills, templates, model outputs and local hook behaviour cannot change that authority. A conflict pauses the affected action and is recorded for resolution.
From conversation to observed outcome
Business validation: contributors supply authorized evidence; the BA reviews the interpretation before the domain owner accepts its exact meaning.
Wide diagrams can be scrolled horizontally; keyboard users can focus the diagram and use the arrow keys in supported browsers. The surrounding paragraphs describe the same workflow.
The BA is the first reviewer of AI extraction, not a forwarding mechanism. Stakeholders receive small questions with context, a proposed interpretation, a visual or working example, and an explicit “unknown” route. Silence is not approval. Meetings remain useful for disagreement and consequential decisions; routine clarification can be asynchronous.
Engineering delivery: the accepted baseline is handed over through a bounded mandate. Verification returns evidence for that candidate; business validation and release retain their own authority.
The architect and developers receive approved intent plus unresolved constraints, not an apparently complete specification that hides guesses. Developers learn the method by delivering a small slice with a coach, reviewing each other's evidence, then taking ownership of adapters, scenarios and improvements. Business participants learn through short guided contributions, not by learning Git or reading an agent transcript.
The handover is a contract, not a document dump
The execution mandate binds one intent baseline to an allowed engineering action. A full PRD helps explain the product, but does not itself grant access, approve a rule or authorize deployment.
| Handover record | Minimum content | Failure behaviour |
|---|---|---|
| Context manifest | Project/tenant, repository and revision, source references and access scope, glossary/taxonomy revision, method/profile, approved model route | Missing identity, inaccessible source or incompatible version stays unknown; no guessed substitute |
| Execution mandate | Approved intent revision/digest, approval reference, bounded objective, allowed tools/resources/effects, required checks, budget, expiry and stop conditions | Reject stale, unacknowledged, expired or out-of-scope work |
| Result receipt | Mandate/run identity, input and output revisions, changed artifacts, actual checks and selections, evidence links, failures/gaps and suggested amendments | A missing/empty receipt is unassessed, not success |
| Release decision | Exact candidate and configuration, evidence reviewed, accountable approver, environment, effective time and recovery plan | Merge/build is not release; release is not business acceptance |
The future workspace owns identity and approvals. S4U owns the method contract and evidence expectations. GitHub may be the first repository adapter; GitLab or another platform should implement the same authority boundary without changing business semantics. Docusaurus renders approved, audience-filtered projections. MCP search must apply the same access and revision filters, cite the retrieved source, and abstain when the available evidence is insufficient.
The reference interface pack
The kit contains four JSON Schema records under contracts/v1/: context manifest, method profile, execution mandate and result receipt. Positive and adverse fixtures exercise identity, required fields, bounded scope, nonempty evidence and simulation/actual distinctions. These are structural contract tests—not an implemented authorization service. The examples contain synthetic, unresolved references and are not executable grants.
An adapter must additionally verify reference digests, current actor/source access, exact approval and presentation, expected-version transitions, required-check coverage, producer provenance, revocation and fencing. The protocol version is independent of the method and product versions. Adopters should first exercise this boundary with an isolated synthetic adapter and explicit failure cases before introducing real effects.
Context is selected, versioned and permission-aware
Private conversation remains private until an explicit contribution is made. Recording permission, access and retention apply independently to the audio, transcript, shared extracts and operational evidence. Summarization must not bypass that boundary. Retrieved instructions are untrusted data; they do not grant tool privileges.
At run start, identify the project, tenant, repository/worktree, exact revisions, environment, profile, tool grants and permitted model endpoint. Retrieve supporting details on demand. A compact manifest is preferable to loading every historical ADR and conversation. Cache and search indexes must enforce current access and deletion decisions; a revoked source must not remain available through a derived answer.
The project glossary contains stable term IDs, definitions, owners, synonyms and approved revisions. The taxonomy defines relationships and classification rules. Map enterprise terminology rather than silently redefining it. If two domains legitimately use a term differently, preserve qualified definitions instead of forcing a misleading universal meaning.
Risk profiles, not a blanket PoC exemption
| Profile | Suitable use | Evidence before that use |
|---|---|---|
| Synthetic prototype | Isolated exploration with synthetic data and no consequential external effects | Scope, safe tooling, targeted behaviour checks, explicit gaps |
| Real-data pilot | Limited authorized users and real personal/confidential information | Applicable privacy, authentication, isolation, critical journeys, retention and recovery checks |
| Production | Operational service with supported users and effects | Complete adopted release gates, independent acceptance, operational ownership, monitoring and recovery evidence |
Stack, repository and integration profiles are additional choices, not replacements for risk controls. The Python/React tooling in the reference kit is one implementation. Another stack must supply equivalent evidence; adopting a different enterprise platform is not automatically a defect.
Local hooks provide developer feedback. Required server checks and protected approval paths need installation and effective-configuration verification. A script, skill or policy file being present does not prove enforcement. Every mandatory assessment distinguishes passed, failed, unassessed and not applicable with rationale. An authorized exception remains visible as an exception.
Declare policy, observe controls, authorize actions
Keep three records distinct: approved policy says what must hold; observation records what a named check actually assessed; authority determines whether the proposed action is permitted. An enforcement register is the reviewed declaration to compare with observed settings, not a substitute for those settings. A human-controlled decision can be valid without an automated detector, but must not be presented as machine-enforced.
Discover relevant producers, consumers and invocation paths where practical, and reconcile them with the approved expected set. A control that writes a gap which no decision surface reads is still ineffective for that decision. Include a new unregistered control, a missing invocation and a dropped consumer in adverse tests. Do not derive the expected inventory and its completeness proof solely from the same markers: both can omit the same path. State the discovery limits and review uncertain applicability.
If a setting cannot be read, report unassessed. A dated, attributed measurement is historical evidence; accepting it for a bounded action needs an explicit freshness and risk policy. It must never be relabelled as a current live observation. Do not provide privileged credentials to untrusted change code merely to make an assessment pass.
Exceptions need stable subject/control/scope identities, reasons, owners and the approval required by policy. Detect newly failing subjects and repaired subjects that remain exempt; a constant exception count does not detect one identity being exchanged for another. Changing a baseline and its comparison test together does not approve the exception. Keep the authorized baseline separate from the proposing change and check it at the decision boundary.
For important detectors, exercise both a prohibited case that must be caught and an allowed case that must remain usable. Where mutation testing is suitable, record a green baseline, the actual unique mutation, the named assertion failure and successful restoration. A timeout, missing test or unchanged input is not a successful detection. Relaxing a control requires renewed evidence for the properties retained, with changed expectations approved separately.
Telemetry readiness is not activation permission. Record the observation window, population or sample, denominator, emitter coverage and known loss. No events can mean no violations or no measurement; missing telemetry must not become zero defects. A useful measure should reach its responsible reviewer, who can evaluate it under the existing grant or seek the required approval.
Adaptation without arbitrary recoding
Use configuration where the runtime already supports the requested variation: terminology, a threshold, required evidence, approved review routing, or a supported workflow step. A new protocol, side effect, security boundary or unsupported algorithm requires a reviewed extension. The collaboration workspace's configurability does not prove that every application it helps deliver is equally configurable.
Approval must bind what the person actually saw: package identity, revision/digest and relevant evidence. An edit invalidates pending approval. At activation, compare the expected version and current state atomically; a prior read followed by an unconditional write is not sufficient. Concurrent approvals, edits and retries need adverse tests, not only a happy-path demonstration.
When an action reaches an external workflow or service, store authorized intent durably before dispatch, use idempotent delivery, and distinguish requested, accepted and completed outcomes. A sent signal does not prove the receiver accepted it. Record retries and reconciliation without inventing exactly-once delivery.
Retain immutable versions of the method, context, intent, rules, workflow and evaluated artifact. Changing the default affects eligible new work; in-flight work remains pinned unless an explicitly approved migration says otherwise. A code rollback cannot unsend a notification, undo a payment or erase a disclosure. Recovery may require compensation, a compatible reader, draining, or human handling.
Existing systems and boundaries
Legacy discovery is an optional intake mode. Begin with source/version inventory, runtime observations, existing tests, operational records and domain interviews. Label extracted rules as observed, inferred, disputed or approved intent. Code is evidence of an implementation, not automatic proof of the desired business policy or deployed version.
For slowly changing legacy, use a pinned baseline, urgent-fix/release notifications and periodic reconciliation. Reinspect the affected scope after a change. Use continuous feeds only when the change rate and risk justify their operational cost. A notification gap must remain visible; do not claim continuous coverage from periodic inspection.
Each integration has a provider and consumer owner, schema and semantic contract, identifiers, authorization, permitted effects, timeout/retry/idempotency policy, failure behaviour, test environment, version policy and observation source. Contract tests, sandbox/live checks and business acceptance answer different questions. A provider mock or behavioural twin helps development but cannot establish the current real provider's contract.
Verification is a portfolio
Protected cases measure disclosed requirements, not secret requirements. The implementer may propose a correction but cannot rewrite protected expectations merely to pass. A second model's agreement is useful review, not an independent oracle. Include false-positive harms, permissions, inaccessible sources, stale approvals, duplicate events, omitted tests and recovery failures alongside normal journeys.
Receipts identify the executed revision, selected subjects, actual command/runner, environment, status and sanitized evidence. Prove both a positive witness and a known failing case for important controls. Generated freshness establishes reproducibility; compilation establishes buildability; neither proves business fidelity. Record concise reasons and evidence, not hidden model reasoning or indiscriminate conversation archives.
Adoption experiment and success criteria
Start with one bounded business capability and one developer team. Onboard each role with its scope and a guided contribution. Run one cycle from authorized evidence through BA review, visual validation, exact approval, implementation, independent tests and a release proposal. Then exercise an adverse cycle: a stale approval, an unavailable provider, or a changed legacy rule.
Measure clarification turnaround, stakeholder effort, accepted corrections, requirement-to-test traceability, escaped defects, rework, unsupported requests, review burden and cost per accepted outcome. Compare with the team's baseline; do not substitute PR counts or token spend for delivered value. Test a configuration-only change and a deliberately unsupported change to demonstrate the product boundary honestly.
Enterprise model deployment is a selected adapter: verify the actual service, model version, processing geography, networking, retention, access and contractual terms. “Private cloud” is not equivalent to zero retention or EU-only processing. The approved route failing must pause model-dependent work, not trigger a public-endpoint fallback. Legal applicability and risk acceptance require the accountable qualified owners.
What this release can establish
The methodology and adoption kit can establish documented controls, tested tooling behaviour and reproducible documentation. They cannot certify an adopter's implementation, legal compliance or production readiness. The future workspace must separately demonstrate identity, access, revision-bound approval, concurrency, durable dispatch and recovery. Keep those acceptance boundaries visible throughout implementation and commercial positioning.