[jrcrittenden]

What

Adds a section to docs/spec/conformance.md, Conformance does not establish human authorization, and one row to the §15 Out of Scope table in docs/spec/instrument/specification.md.

1. The scope statement. Conformance at any tier establishes the technical properties of the claimed profile. It does not attest asserted governance facts: whether an Approver is human, whether that human contemporaneously authorized the action, or whether the Approver held valid institutional authority. ACS can authenticate an approver credential and record a declared human approver (approver.type, approver_types_supported, Guardian-verified identity in §9) without establishing human volition behind it, and per trust.md a Guardian MUST NOT treat an asserted fact as attested.
2. One normative requirement. At any tier, a deployment MUST NOT represent its ACS conformance, by itself, as satisfying a requirement for human authorization or institutional oversight, or as evidence that a human authorized a specific decision or act.
3. The governance crosswalk. Conformance does not by itself satisfy NIST AI RMF GOVERN 2.1, 2.3 and 3.2 and MAP 3.5, MAESTRO's Layer 6 Security & Compliance governance surface, or OWASP LLM06:2025's recommendation that a human approve high-impact actions. ACS can record evidence relevant to those processes; it does not substitute for them.
4. The §15 row. Bootstrap authority and delegation-chain attestation, deferred to v0.2: whether policy, initial Intent and Approver configuration were adopted through an accountable process, and whether a claimed authority is backed by a delegation chain, is verified outside the protocol in v0.1. The conformance section points to it.

No wire-format changes and no new profiles. The MUST NOT in item 2 is a new conformance requirement on deployments.

Why

ACS produces exactly the artifacts governance reviews look for: decisions, audit chains, verified Approver identities. A fully conformant deployment can produce all of them with no human anywhere in the loop: policy authored by automation, every ASK answered by an automated service, the audit chain complete and intact. Nothing on the wire distinguishes it from a human-governed deployment. Without scope language, conformance will be cited as governance evidence, and the spec should say plainly that it is not.

Relationship to existing work

• PR Identity Initial Overview and Big Picture #9's identity workstream (Challenge Bump idna from 3.10 to 3.15 #5, Proof of Intent) already identifies human-approved Intent extension as a requirement. This section is the complement: it states the current limits while that mechanism is worked.
• The policy-author attestation profile (§16) is named in the §15 row as the first step toward the deferred attestation.

Closes #136.

[rocklambros]

Jason, the argument is right and I want it in the spec. I came at it from several angles and could not break the core: a conformance label says something about protocol behavior, not about whether a person stood behind the decision. That belongs in this chapter.

What I can't merge is the text, because I checked all three citations against the sources and all three are off:

• MAESTRO Layer 7 is Agent Ecosystem, the marketplace surface. Governance and compliance is Layer 6, the vertical layer cutting across the other six, which fits your argument better anyway.
• LLM06:2025 is Excessive Agency. The bullet you paraphrased, "implement authorization in downstream systems rather than relying on an LLM to decide if an action is allowed," is about which component decides, not about human authority. The one you wanted sits two lines below it: "utilise human-in-the-loop control to require a human to approve high-impact actions before they are taken."
• None of the three is a requirement. NIST AI RMF is voluntary, MAESTRO is a threat-modeling method, the OWASP list is awareness guidance. Our own landing page says so at line 121.

The LLM06 one worries me most. A Guardian that decides outside the model, with decision honoring as a MUST, is roughly what that bullet asks for. As written, the sentence has ACS disclaiming the OWASP guidance it implements, in a spec that ships under the OWASP banner.

The other thing I'd change is "nothing in the protocol can distinguish it from a human-governed one," which isn't true as stated. The protocol distinguishes those cases in three places:

• approver.type is a required field with a human/agent/service enum
• handshake.json negotiates approver_types_supported before any traffic moves
• §9.1 makes the Guardian write approver identity into the chain

An honestly configured automated deployment declares itself every time. I think you meant attestation rather than syntax, and that version is truer and sharper: the protocol records the declared approver type and does not attest it. trust.md already has the words for it, including "a Guardian MUST NOT treat an asserted fact as attested." Written that way, the paragraph reinforces the trust model instead of appearing to fight it.

Same shape of problem with "authority absent at initialization cannot be added afterward from within the protocol." That runs into intent.md:21, which calls the ASK intent-extension flow the only conformant path to widen Intent. My guess is you meant bootstrap authority rather than in-session capability, and the text doesn't draw the line.

Then there's one real decision to make, not a fix. SPEC_REVIEW_PRINCIPLES.md says spec text is normative unless marked otherwise. Your three paragraphs carry no RFC 2119 keywords and no non-normative marker, in a chapter that has eighteen of them. That leaves "conformance alone cannot satisfy any requirement for human authorization or oversight" binding today, without bounds, while obliging nobody to do anything. Two ways out, either works:

• Give it teeth, something like "a deployment MUST NOT represent ACS conformance as evidence that a human authorized a specific action"
• Mark the section non-normative

Right now it carries a disclaimer's cost without its protection.

Smaller things worth a pass:

• The opening sentence credits Core with honoring decisions, but on_decision_failure defaults to proceed, so a conformant deployment under disruption proceeds with no decision at all.
• All three paragraphs sit inside ## ACS-Core while scoping themselves to "any profile above it," so anyone deep-linking to #acs-audit misses them.
• The closing line about risk growing with conformance quality reads like automation bias, which is probably right, but it has no citation and everything else in the chapter is checkable.

The last paragraph is the one I'd move rather than edit. "Publicly authorized bootstrap," "Intent scope," and "institutional accountability" appear nowhere else in the repo, and "Intent scope" sits close enough to scope_mode to confuse someone later. conformance.md:69 already names the mechanism you're reaching for, the future Policy Attestation profile, and §15 Out of Scope is where we track that kind of commitment with a version attached. That's its home.

Two things I hit that aren't yours, and I'll file them separately:

• specification.md has no ## 9 heading at all, so the approver model is stranded inside §8.6 and the §9 links from three concept pages go nowhere.
• ask-details.json leaves auth out of required while calling it "for non-human approvers," which contradicts §9's "approver authentication is REQUIRED."

[rocklambros]

Two corrections to the note at the bottom of my review, since I went and worked both of them.

The §9 references from the concept pages are bare text rather than links, so nothing was a broken hyperlink. The heading was genuinely missing and the section had no anchor and no table-of-contents entry, but I described the symptom wrong. Fixed in #50, which adds ## 9. Approver Model plus a structural test that catches orphaned subsections across every numbered document.

I framed the ask-details.json one too broadly too. The "for non-human approvers" scoping is defensible, since endpoint carries the same scoping and a human approver authenticating through an IdP has no bearer or mtls value to put on the wire. The narrower gap is that auth stays optional even for the machine approvers it is scoped to, so a payload can name a remote endpoint with no authentication and still validate. Filed as #51 with options rather than a patch, because tightening required is a breaking change on a frozen v0.1.0 whose schemas serve live.

Neither changes anything I asked for on this PR.

[rocklambros]

@jrcrittenden I moved this to integration and linked it to #136, which I filed and accepted so the PR has an issue behind it. main only takes promotions and a few allowlisted paths now, and docs/spec/ isn't one of them. CI is green on the new base.

Your 09-14 rewrite closed almost everything from my September review. I checked MAESTRO Layer 6, the LLM06 human-in-the-loop bullet, and all four NIST subcategories against the sources, and they're right now.

Two things before I can merge it. The commit is authored by Hermes Agent with no Signed-off-by, and CONTRIBUTING.md asks for a human author and a sign-off on every commit, so that one has to come from you: git commit --amend --reset-author -s. Keep the Co-Authored-By trailer if you want it. Second, the last paragraph is still in the conformance chapter rather than §15 Out of Scope, where we track commitments with a version attached, and it's the natural home for the bootstrap and delegation-chain language.

One smaller thing. The Lanero citation is a study of eco-labels on bananas, and calling that an adjacent certification domain is a stretch. I'd cut those two sentences: the MUST NOT stands on its own without them.

[jrcrittenden]

Done - thank you.

[rocklambros]

@jrcrittenden, GitHub wouldn't let me assign you issue #136, and I think that's because you haven't commented on it yet. Can you leave a comment there saying you're on it? Then I can assign you.

[rocklambros]

Jason, the section now separates what the protocol records from what it can't attest, and the trust.md link lands on the rule it quotes.

Everything I asked for on 09-06 and 09-17 holds, so this approval replaces my changes request.

I also checked each citation at the publisher, and all three are right. NIST AI 100-1 has GOVERN 2.1, 2.3, 3.2 and MAP 3.5 as you describe them. OWASP LLM06:2025 has the line about a human approving high-impact actions. CSA calls Layer 6 Security & Compliance, and its October 2026 MAESTRO post puts "governance policy and audit logging" there.

I built the merged tree on integration 19b1197 and ran everything. Pytest gives 923 passed and 1 skipped, mkdocs build --strict is clean, and the agt suite ran 1287 tests with 0 failures on Bun 1.3.11 and 1.3.14. All of that matches integration alone. The three new anchors resolve in the built site.

This one is normative, so I won't merge it on my approval alone. conformance.md:49 adds a new requirement on deployments, and the section has no non-normative marker. The PR description still says "no new conformance requirements." That line is older than your rewrites, so please go by the diff.

@bar-capsule @afogel, can one of you make these two spec calls?

1. docs/spec/conformance.md:49. Do you accept this MUST NOT in v0.1.0? Issue #136 named only "evidence that a human authorized a specific action." The text also covers "satisfying a requirement for human authorization or institutional oversight." It binds "a deployment," while the claim template calls the party making the claim the Claimant. If you want it narrower or aimed at the claimant, can you ask Jason to change that sentence?
2. docs/spec/instrument/specification.md:432, the new §15 row. Is v0.2 right? §16 lists only the policy-author attestation profile for v0.2.0, and the row calls that "the first step." The v0.2.0 milestone has no issue for delegation-chain attestation. If that part can land later, the value should be v0.2+, like the gRPC row.

If both are fine as written, please approve and merge. That closes issue #136, which is assigned to Jason. A change needs one push from Jason, and that push clears my approval, so I'd review again. If he pushes anyway, NIST says AI RMF 1.0 is being revised, so conformance.md:51 should say "NIST AI RMF 1.0" to pin those numbers.

To merge, squash to integration at head c3c80b81785b4deb2f9ae23bd4550a73c54c3d83. The commit body is Closes #136, then the trailers from Jason's commit word for word, then your sign-off.

[github-actions]

This pull request's description says it closes #136, which is on the project roadmap. When it merges, GitHub closes that issue and the roadmap counts it as delivered. Please confirm the change delivers the whole issue before merging.