테마
승인 기반 제조 업무 실행
BOM 변경·PCF 계산과 교환·품질 최초 전송·인증서 교환을 프로그램으로 진행할 때 쓰는 참조입니다. 먼저 제조 자료 매핑으로 입력을 확인한 뒤, 각 업무의 준비 → 소유자 웹 승인 → 실행 → 영수증 조회 순서를 따릅니다. 단일 제품을 처음 등록한다면 정식 등록부터 읽으세요.
이 문서는 구현된 동작을 설명합니다. 연결이 허용된 개발 환경에서 접속 서버의 최신 tools/list, 필요한 schema 배포, 제공자 allowlist와 실행 설정을 확인합니다. 설정이 비어 있으면 실행이 꺼집니다.
| 할 일 | scope | 다음 확인 |
|---|---|---|
| BOM 변경 | bom:write | 부모 revision·자식 수량/단위·다음 단계 |
| PCF 계산·확정·최초 생성 | pcf:write | 서버 계산 미리보기·고정 입력·게시 상태 |
| PCF 요청·전송 | pcf:exchange | 대상과 확정한 자산 revision·영수증 |
| QN 최초 전송 | quality:write | CREATED 알림·준비된 RECEIVE 채널 |
| 인증서 교환 | ccm:exchange | 작업 종류·준비된 채널·고정한 인증서 |
도구 이름은 승인 기반 도구 표에서 찾을 수 있습니다.
등록 → BOM → PCF 또는 계약 → 별도 전송의 진행을 한 ID로 추적하려면 복합 업무 따라 하기를 사용하세요. 각 원래 승인과 명시적 단일 실행 조건은 유지됩니다.
공통 순서
- 필요한 scope가 프로그램 생성 때 선택한 허용 목록에 있는지 확인하고, 이번 작업에 필요한 범위로 로그인해 동의를 받습니다. 목록이 부족하면 새 프로그램을 등록해 설정을 교체합니다. 기존 client/grant에 묶인 검토·승인은 재사용하지 않고 현재 실행 범위의 연결로 다시 준비합니다.
- 조회·미리보기로 실제 자산 ID와 revision, 필요한 입력을 확인합니다. 누락된 단위·기간·출처를 추측하지 않습니다.
- 안정적인
createKey로 준비 도구를 호출하고 반환한 검토 링크를 사용자에게 표시합니다. - 원래 조직 소유자가 로그인해 고정된 내용·정책·대상·계산 결과를 확인하고 승인합니다. AI가 승인 API를 대신 호출하지 않습니다.
- 실행 도구를 호출합니다. 불변 BOM·PCF 공개는 조회 결과의
nextStepKey를stepKey로 보내 한 번에 한 단계만 진행합니다. 같은 키의 재호출은 다음 단계로 넘어가지 않습니다. - 영수증을 조회해 원격 수락·로컬 반영·최종 공개를 구분합니다.
needs_reconciliation이면 자동 재시도와 새 키 우회를 중단합니다.
BOM과 최초 PCF
BOM 준비는 부모 자산·기대 BOM revision·자식별 수량과 단위를 받습니다. 등록된 제품은 기존 공개 본문을 바꾸지 않고 새 불변 버전을 만듭니다. 제품 조회 infirium_get_product_data는 현재 BOM을 합성하며 PCF 본문을 제외합니다. PCF 조회는 pcf:read 동의로 infirium_get_pcf_data를 사용합니다. 과거 버전을 명시적으로 조회하면 historical 표시를 반환합니다.
PTI만 등록한 제품의 최초 PCF에는 infirium_preview_pcf_initial_calculation을 사용합니다. 명시적 grouped v9 선언과 pcfCalculationInputs를 제출하고 서버가 계산합니다. 계산 총량·fingerprint·집계 결과를 사용자가 검증된 값처럼 제출할 수 없습니다. 준비 시 부모 revision과 미리보기의 BOM revision을 함께 고정합니다. 이미 PCF가 있으면 기존 PCF 계산 확정 도구를 사용합니다.
등록 제품의 기존 PTI·과거 BOM·과거 PCF 본문은 보존됩니다. PCF 전송은 계산 확정과 별도이며 완료 영수증의 공개 자산 ID·revision을 사용합니다. 계수·생산 기간·단위·자식 PCF가 바뀌면 새 검토가 필요합니다.
기존 INLINE PCF 계산 확정도 서브모델 리비전 이력에 기록합니다. 새 PCF ID·이전 판 연결·본문과 발행 정보를 검토 전에 고정하며, 승인 뒤 원본·현재 판·초안 상태가 바뀌면 실행을 거절합니다. 동일한 계산 결과는 새 ID나 리비전을 만들지 않습니다. 등록된 불변 PCF 버전은 별도 버전 경로를 유지합니다.
마지막 DTR 단계의 응답이 끊긴 경우
등록 제품의 불변 BOM·PCF 게시에서 앞 단계가 수락됐고 마지막 DTR 단계만 needs_reconciliation이면 원래 검토의 조회 도구를 사용합니다. 서버가 원래 검토의 현재 권한·자료·대상을 다시 확인한 뒤 승인된 주소에서 원래 항목을 제한된 GET으로 확인하고, 식별자와 전체 본문을 원래 요청과 대조해 수락 영수증을 기록할 수 있습니다. 원문 전체 digest가 같거나, 아래의 최상위 빈 배열 규칙을 적용한 전체 digest가 수정하지 않은 원래 요청의 전체 digest와 같아야 합니다. 조회가 새 전송이나 최종 게시를 실행하지는 않습니다.
조회 결과가 수락으로 바뀐 뒤에는 반환된 nextStepKey를 확인하고 별도의 실행 도구로 최종 게시를 요청합니다. 현재 권한과 원본 검사는 계속 적용됩니다. 404·시간 초과·허용된 최상위 빈 배열 차이 외의 다른 본문은 성공으로 바꾸지 않으며, 다른 단계의 불확실 결과를 이 방식으로 복구하지 않습니다. 새 검토·새 키로 같은 DTR 등록을 다시 보내지 마세요.
빈 배열 규칙은 DTR SubmodelDescriptor의 최상위 displayName·description·supplementalSemanticIds·supplementalSemanticId가 []인 경우에만 적용합니다. 해당 항목만 제외한 응답 전체를 비교하며 중첩·사용자 정의 필드나 비어 있지 않은 배열은 제거하지 않습니다. 별도 ingress의 정리된 응답이나 일부 필드 일치로 대체하지 않습니다. 조건에 맞지 않으면 needs_reconciliation을 보존하며 새 DTR POST나 새 키로 우회하지 마세요.
품질과 인증서 교환
품질 최초 전송은 기존 CREATED 알림과 준비된 RECEIVE 채널을 사용합니다. 인증서는 요청·직접 push·응답 push·available·상태 통지를 각각 준비합니다. available은 이미 공개한 인증서 자산이 있어야 합니다. 채널 생성·EDR 갱신·재연결·협상·인증서 공개를 몰래 수행하지 않습니다. 이미 공개한 인증서라도 준비 단계가 publication 검증을 거절하면 검토·실행이 생성됐는지 먼저 확인하고, 새 공개 요청이나 전송으로 우회하지 마세요. 수락·완료를 확인한 뒤에도 검토·클라이언트 회수와 허용된 감사 기록 보존을 각각 확인합니다. 연결 동의를 회수하면 해당 동의에 묶인 검토 조회도 제한될 수 있습니다.
현재 QN·인증서 소스에 권위 있는 그룹 소유 정보가 없으면 그룹 한정 연결을 거절합니다. 버전 고정 읽기가 없는 인증서 외부 저장소도 거절합니다. 이 조건을 만족하지 않은 고객 데이터는 지원 완료로 간주하지 않습니다.
개별 승인한 정식 등록을 배치로 진행
배치는 기존 조직 소유자가 각각 승인한 검토 1~10개를 묶는 조정 도구입니다. 다섯 도구 모두 products:register와 원래 소유자·조직·그룹·client·grant의 현재 권한을 요구합니다. 배치 생성으로 일괄 승인되지 않으며 원본·의존성·승인 내용이 바뀌면 기존 실행 검사를 그대로 적용합니다.
| 도구 | 입력 | 한 번의 호출 효과 |
|---|---|---|
infirium_create_registration_batch | {idempotencyKey, reviewIds} | 승인된 검토 1~10개를 입력 순서대로 고정. provider 요청 없음 |
infirium_get_registration_batch | {batchId} | 항목별 상태·영수증·다음 동작 조회. 실행 없음 |
infirium_execute_registration_batch_step | {batchId, itemId, stepKey} | 선택한 항목의 정확한 단계만 provider 최대 1회 실행. 다른 항목·다음 단계로 자동 진행하지 않음 |
infirium_resume_registration_batch_item | {batchId, itemId} | 전송되지 않은 것으로 확인된 재시도 가능 실패만 로컬 pending으로 복구. 별도 execute 호출 필요 |
infirium_cancel_registration_batch | {batchId} | 새 단계 시작과 로컬 게시를 영구 차단. provider 요청 없음 |
ID와 idempotencyKey는 UUID이며 stepKey는 조회에서 받은 정확한 1~64자 값입니다. 같은 생성 키·같은 순서 입력은 같은 배치를 반환하고, 같은 키의 다른 입력이나 중복 검토는 거절합니다. 항목과 순서는 생성 뒤 바꿀 수 없습니다. 조회는 read 예산, 나머지는 prepare 예산을 사용합니다.
항목별 nextAction은 execute_step, resume, reconcile, none이며 nextStepKey·blocker·continuationAvailable을 함께 확인합니다. 마지막 외부 단계가 완료돼도 로컬 게시가 남으면 반환된 마지막 성공 stepKey로 명시적 execute가 필요할 수 있습니다. 동일 단계 재호출로 다음 단계나 다른 항목을 실행하지 않습니다. needs_reconciliation이나 진행 중인 외부 요청에는 resume을 사용하지 않습니다.
배치 취소는 이미 발생한 외부 효과를 되돌리지 않습니다. 취소 전에 시작이 확정된 요청은 뒤늦게 완료될 수 있고 영수증은 보존됩니다. retainsExternalEffects와 항목별 영수증을 확인합니다. 취소된 배치는 재개할 수 없고 기존 단일 등록 도구로 취소·만료를 우회할 수 없습니다. partial, published, blocked, cancelled, expired는 별개 상태이며 배치 생성이나 일부 성공이 전체 정식 게시를 뜻하지 않습니다.
원격 ID 없는 불확실 결과의 운영 인수
현재 조직 소유자가 정상 웹 인증으로 사용하는 /program-recovery API는 인수·담당 확인·제한된 조사 요약을 로컬에 기록합니다. MCP 도구나 새 OAuth scope를 추가하지 않으며 원래 실행·승인 권한을 대체하지 않습니다. 모든 route는 현재 소유자·조직·구독·그룹·실제 source 소유 범위를 검사하고 assist/delegation 접근을 거절합니다.
| HTTP 경로 | 용도 |
|---|---|
POST /program-recovery/cases | {source, idempotencyKey}로 불확실 결과 접수 |
GET /program-recovery/cases | 자기 조직의 읽을 수 있는 case 조회. limit 기본 20, 최대 100 |
GET /program-recovery/cases/:id | view=current 또는 명시적 view=history로 metadata 조회 |
POST /program-recovery/cases/:id/events | 현재 revision에 맞는 acknowledge 또는 evidence 요약 추가 |
GET /program-recovery/maintenance | 자기 조직 backlog와 마지막 기록된 정리 작업 상태 조회 |
초기 접수 대상은 remoteId=null이고 이미 needs_reconciliation으로 기록된 EDC consumer 실행(consumer_negotiation, consumer_transfer, consumer_transfer_terminate) 또는 정식 등록 job의 정확한 step입니다. source는 {kind:"edc_execution", jobId} 또는 {kind:"registration_step", jobId, stepKey}입니다. in_flight/dispatching, 알려진 remote ID, 별도 BOM·PCF·QN·CCM reviewed 실행과 A2A task ID만 있는 결과는 이 접수 대상으로 바꾸지 않습니다. A2A를 통해 실행했어도 지원하는 원래 journal을 선택해야 합니다.
이 API는 provider GET/POST, 재전송, reconcile, publish, resume, 원격 취소를 수행하지 않습니다. 조사 요약이나 matched_presence는 수락 영수증이 아닙니다. canonicalOutcome:"unknown"과 outcomeMeaning:"at_intake"는 접수 당시의 불확실 결과를 뜻하며 현재 사실 결과는 원래 권한의 정상 journal 조회에서 확인합니다. 원격 ID·승인·dispatch 시각·journal 상태를 주입하는 입력은 없습니다.
current의 원래 검토·grant·원본 freshness와 history_only의 동결된 인수 이력을 구분합니다. history도 현재 소유자와 live source 소유 범위를 다시 검사하며 삭제·이전된 source의 읽기 권한을 만들어내지 않습니다. 과거 이력을 읽어도 실행을 계속할 권한은 생기지 않습니다. 접속 릴리스의 배포·검증 근거를 확인한 뒤 사용합니다.
웹에서 조사하기
조직 소유자는 AI 연결 설정의 실행 복구 조사(/setting/program-access/recovery)에서 접수·상태별 목록·담당 확인·조사 요약·이벤트 이력·마지막 worker 관측을 확인할 수 있습니다. 원문 로그·고객 자료·자격 증명은 입력하지 않습니다. revision 충돌이 발생하면 새로고침한 뒤 다시 판단하며 저장을 자동 재시도하지 않습니다. 일반 멤버와 대리 세션, 기능이 꺼진 환경에서는 접근할 수 없습니다.
등록 사건의 현재 metadata 확인 뒤에는 원래 소유자의 정상 검토 API를 통해 DTR 수락 확인 자격을 별도로 검사합니다. 정식 등록의 DTR 수락 확인은 provider GET만 사용하는 독립 소유자 명령입니다. 조사 API 자체는 계속 metadata만 다룹니다. matched_presence 조사 기록이나 과거 이력을 읽었다는 사실이 수락·재실행 권한을 만들지 않습니다.
고객 컴퓨터에서 PDF·이미지 추출
고급 로컬 파일 평가·추출에서 실행 환경·명령·예상 출력을 확인하세요. 로컬 추출은 external/unverified, review_required, applySupported:false 결과이며 업무 레코드·품번·매핑을 자동 확정하지 않습니다. headers·records·행별 OCR 페이지·단위·schema·draft 기준은 제조 자료 매핑에서 별도로 검토합니다.
A2A와 운영
동일 업무는 AgentCard의 허용 도구에 한해 A2A 구조화 메시지로 위임할 수 있습니다. OAuth audience와 사람 승인 조건은 같습니다. 승인 대기·후속 단계·불확실 결과는 TASK_STATE_INPUT_REQUIRED로 반환하며, Task 완료가 원격 계약·전송 완료를 뜻하지 않습니다.
배치·복구 기능은 접속 릴리스의 필요한 schema와 코드가 준비돼 있어야 합니다. 배포 담당자는 저장소의 내부 배포 런북에서 환경별 준비 상태를 확인합니다. 현재 운영 MCP·AI A2A 차단은 유지됩니다.
비밀·원문·EDR은 AI 입력이나 일반 로그에 복사하지 않습니다. 오류는 재시도·운영 인수 조건에 따라 처리하며 원래 검토·실행 식별자를 유지합니다.