Verified Digital Agents → Samples → Genesis extraction

Genesis From Card — Extracted Governance Inputs

Sample artefact — synthetic data (Northwind Bank)

Produced by C2MD extract_governance_inputs. How this skill works →

DOCUMENT STATUS — DEMO DATA · NOT FOR REGULATORY RELIANCE.

Input — the agent's own card

{
  "name": "Northwind Credit Decision Assistant",
  "description": "Evaluates consumer loan applications and returns an
                  approve / decline / refer recommendation with a reason
                  code, using applicant-supplied financial data and
                  internal repayment history.",
  "provider": { "organization": "Northwind Bank" },
  "skills": [
    { "id": "evaluate_application", "tags": ["credit", "underwriting"] },
    { "id": "return_decision",      "tags": ["decision", "reason-code"] },
    { "id": "escalate_to_human",    "tags": ["oversight"] }
  ]
}

Output — proposed inputs, for review

Input	Proposed	Derived from	Confidence
`data_categories`	`[financial, identity, behavioural]`	"applicant-supplied financial data", "internal repayment history"	High
`autonomy_level`	`assistive`	Card returns a recommendation and declares `escalate_to_human`; it does not declare a capability that commits the decision.	Medium — see below
`industry`	`banking`	Provider organisation and skill tags `credit`, `underwriting`.	High

Why autonomy_level is only medium confidence — and why that matters most. The card says "recommendation", but a recommendation that is accepted automatically downstream is, in substance, a decision. The card cannot show what happens after it returns. This is precisely the field a human must confirm or correct, and precisely why the output is a proposal rather than a setting.

The human step

A reviewer confirms or corrects each value. In this example the reviewer corrected the autonomy level:

autonomy_level: assistive → assistive   (confirmed)
  reviewer note: "'refer' path routes to a credit officer with authority
  to overturn; no auto-accept downstream. Confirmed assistive."

data_categories: [financial, identity, behavioural]   (confirmed)
industry: banking                                     (confirmed)

The ratification handoff

Those confirmed values are what ACP raises for sealed ratification:

ACP  → raise_hitl_item
        class: governance_ratification
        statement binds each value as field=value tokens:
          autonomy_level=assistive
          data_categories=financial,identity,behavioural

HITL → routes to the authorised band (governance_owner)
     → records the asserted actor separately from the
       authenticated account
     → seals a hitl_decision to Witness

ACP  → activation gate resolves the item LIVE and refuses unless it is
       resolved, approved, sealed (not pending), the sealed statement
       binds every ratified value, and the deciding actor holds
       authority under CODEOWNERS.

The gate fails loud. If HITL is unreachable, if the seal is still pending, or if the actor lacks authority, activation is refused. A ratification that cannot be resolved is never treated as a pass — which is what makes "who approved this governance, and can you prove it" answerable rather than assumed.

Resulting manifest

{
  "schema": "acp.ratification/2",
  "ratified": [
    { "field": "autonomy_level",  "value": "assistive" },
    { "field": "data_categories", "value": "financial,identity,behavioural" }
  ],
  "hitl": { "caller_id": "clr_…", "item_id": "itm_…" }
}

The manifest references the HITL item rather than embedding a record — the seal stays where seals live, and the git artefact carries a pointer to it.