ZAYAZ Artifact Manifest Generator Schemas

1. Canonical route binding schema

This is the logical shape ZAMG/docs/tools should generate from or align to.

canonical-route-binding-schema.yamlGitHub ↗
api_binding_id: "api.exports.xbrl.post.v1"
route_template: "/api/v1/exports/xbrl"
http_method: "POST"
api_version: "v1"

binding_name: "Export XBRL"
description: "Maps XBRL export API requests to the canonical XBRL export opcode."

operation_key: "export_xbrl"
opcode: "OP_0910"

artifact_type: "exporter"
target_resolution_mode: "manifest_capability"
target_cmi: null
target_cmi_version: null

input_contract_type: "report_package"
output_contract_type: "disclosure_artifact"

request_mapping_profile: "xbrl_export_request_v1"
response_mapping_profile: "xbrl_export_response_v1"

ruleset_profile_code: "XBRL_EXPORT_DEFAULT"
requires_zssr: true

public_api_allowed: true
partner_api_allowed: true
internal_api_allowed: true

execution_mode: "hybrid"
idempotency_supported: true
auth_profile_code: "bearer_tenant_user_v1"
tenant_scope_mode: "caller_scoped"

route_params_schema: {}
query_params_schema: {}
request_body_schema:
  type: object
  required: ["report_id", "taxonomy", "format_version"]
response_body_schema:
  type: object

fixed_context:
  invoked_via: "api"
default_input_payload:
  export_type: "xbrl"

source_manifest_id: null
source_manifest_ref: null
source_notes: null

status: "active"
lifecycle_status: "active"
version: "1_0_0"
sort_order: 100

Design notes

Why operation_key and opcode both?

Because:

operation_key is more readable and useful for docs/generation
opcode is the canonical runtime semantic binding

Why target_resolution_mode?

Because some routes should:

point directly to one artifact
point to an artifact type family
resolve through manifest capability
dispatch to a workflow template

Why both public_api_allowed and partner_api_allowed?

Because later:

public API surface
partner ESGX alias layer
internal-only routes

should be separable.

2. Canonical ESGX binding schema

canonical-esgx-binding-schema.yamlGitHub ↗
esgx_code: "ESGX_4jbj6c76_0950"
esgx_hash: "4jbj6c76"
opcode_suffix: "0950"

binding_name: "BigCorp Latest Quarterly Report Pull"
description: "Partner-scoped external alias for pulling the latest quarterly report for BigCorp."

partner_id: "partner_bigcorp"
client_id: "client_bigcorp"
tenant_id: null
owner_org_id: "org_bigcorp"

operation_key: "pull_from_external_system"
opcode: "OP_1410"

api_binding_id: "api.reports.quarterly.pull.post.v1"
artifact_type: "connector"
target_resolution_mode: "manifest_capability"
target_cmi: null
target_cmi_version: null

ruleset_profile_code: "BIGCORP_QREPORT_PULL_V1"
auth_profile_code: "partner_bearer_v1"
execution_mode: "async"
requires_zssr: true
idempotency_supported: true

partner_api_allowed: true
direct_esgx_allowed: true
internal_api_allowed: false

tenant_scope_mode: "caller_scoped"
caller_scope_mode: "partner_scoped"

input_contract_type: "external_pull_request"
output_contract_type: "external_pull_result"

default_input_payload:
  report_type: "quarterly"
  latest: true
  client_code: "bigcorp"

fixed_context:
  invoked_via: "esgx"
  partner_context: "bigcorp"

request_constraints:
  allow_period_override: false
  allow_client_override: false

response_projection:
  profile: "bigcorp_qreport_response_v1"

route_binding_required: false
route_binding_override_allowed: false

usage_limit_profile: "partner_standard"
security_class: "high"
compliance_impact: "medium"
trust_threshold: 0.88

status: "active"
lifecycle_status: "active"
version: "1_0_0"
sort_order: 100

valid_from: null
valid_to: null
source_notes: null

GitHub Repo Request for Change (RFC)

1. Canonical route binding schema​

Design notes​

2. Canonical ESGX binding schema​

1. Canonical route binding schema

Design notes

2. Canonical ESGX binding schema