기록을 만들고 다음 본문에 전달하기

업데이트: 2026-10-04. 개발 후보 fa3c8927의 구현 #1223은 개발 브랜치에 병합됐고, main #1224의 배포 검사를 마쳐 main b629a664로 두 실행기를 설치했습니다. 아래 실행 명령은 이 설치 소스를 기준으로 합니다. 실행 관측 #9는 21개 검사 통과 후 연구 main으로 병합됐습니다. 현재 설치 리비전과 병합 상태는 현재 상태에 따로 기록합니다.

작은 서류를 작업대 사이에 전달합니다

Candidate가 제목과 상태를 담고, 다음 활동이 상태를 읽어 Review를 만들 수 있습니다. 기록은 이름과 자리가 정해진 서류에 가깝습니다. 연결선은 서류 전체를 전달하고, 관측에는 실제 필드값이 남습니다.

entity Candidate id "records://candidate" fields {
    field title id "records://candidate/title" type string required one
    field state id "records://candidate/state" type string required one
}
activity Propose(Integer, Text) -> Candidate computes `
if input0 >= 0 {
    return Candidate{title: input1, state: "ready"}
} else {
    return Candidate{title: input1, state: "wait"}
}`
activity Echo(Candidate) -> Candidate computes "return input"
bind Propose.result -> Echo.input

이는 선언 부분을 보여주는 예제입니다. 실행할 때는 Integer·Text와 조립 규칙까지 포함한 아래 전체 파일을 사용합니다. 현재 필드는 필수 문자열 한 값입니다. 기록은 최대 16개, 각 기록의 필드는 최대 16개이며, 활동의 입력도 선언 순서로 최대 16개까지 받을 수 있습니다. 정수·참거짓·텍스트와 기록을 섞을 수 있습니다.

본문에서 쓸 수 있는 동작

동작	예
전체 기록 구성	Candidate{title: input1, state: "ready"}
필드 읽기	input.state
지역값으로 복사	let copy = input
지역값 전체 교체	copy = Candidate{title: copy.title, state: "wait"}
전체 기록 반환	return copy
같은 기록 타입의 값 비교	input0 == input1

생성자는 모든 선언 필드를 이름으로 한 번씩 채웁니다. 입력은 읽기 전용입니다. 지역값 전체를 교체하는 방식으로 변경을 표현합니다. 네이티브 코드는 선언한 순서의 Go 값 구조체를 사용하고, 안정적 ID에서 타입·필드의 이름을 정합니다. JSON에는 소스의 title, state 같은 이름을 유지합니다.

선택 필드·여러 값·중첩 기록과 다른 필드 타입은 이후 엔티티 프로파일 작업입니다. 호출·반복·외부 효과는 각 실행 계약을 더 준비해야 합니다.

한 명령으로 실행합니다

예제용 새 체크아웃에서 관측한 후보를 빌드합니다. 작업 중인 파일이 있는 체크아웃은 변경을 보존하고 별도 예제 폴더를 사용합니다.

git clone --depth 1 https://github.com/kimjooyoon/meta-ontology-go.git
cd meta-ontology-go
git fetch --depth 1 origin b629a664ea4a667945ab5f894557f42e97cafa35
git switch --detach FETCH_HEAD
gooo_go_bin="$(GOTOOLCHAIN=go1.27.1 go env GOROOT)/bin/go"
"$gooo_go_bin" build -trimpath -o gooo ./cmd/gooo
./gooo body-compose \
  --source examples/body-codegen/native-records.gooo.fixture \
  --cases examples/body-codegen/native-records-cases.json \
  --out record-results

새 폴더에 원본, 선택된 Gooo, Go 함수, 연결 드라이버와 실제 결과를 보관합니다. 기본 경로는 결정론적입니다. 여섯 사례의 각 활동 결과를 확인해 36/36을 충족하면 제공한 이름 있는 기대값 36개와 일치한 것입니다.

자체 모델의 고정된 공개 파일 두 개를 받아 연결할 수 있습니다.

hf download asketeddy/gooo-three-choice-feedback-tiny-v1 \
  models/set-feedback/fp32/model.json models/set-feedback/fp32/weights.bin \
  --revision 24238ca67048b36bc305731799985271bb752dd1 \
  --local-dir gooo-models
./gooo body-compose \
  --source examples/body-codegen/native-records.gooo.fixture \
  --cases examples/body-codegen/native-records-cases.json \
  --model gooo-models/models/set-feedback/fp32/model.json \
  --out record-model-results

모델은 Score의 정수 연산 배치를 제안합니다. 기록의 필드 구성과 읽기는 Gooo에 적은 본문을 따릅니다. 모델과 결정론 경로 모두 같은 최종 소스와 코드를 만들었습니다. 모델의 첫 후보는 0/6, 후속 후보는 6/6 예시를 충족했습니다. 가중치는 이번 작업에서 새로 학습하지 않았습니다.

저장한 구성은 새 추론 없이 실행합니다. 출력 폴더는 매번 새 이름을 사용합니다.

./gooo body-compose \
  --source record-model-results/original.gooo \
  --cases record-model-results/cases.json \
  --composition record-model-results/composition.json \
  --out record-replay-results

결과를 읽는 순서

1. runtime.json의 finite_passed, finite_total로 작성한 기대값의 충족 수를 봅니다.
2. traces[].deliveries[]의 actual과 expected를 비교합니다.
3. 기록 출력은 actual_fields, 단일 기록 입력은 input_fields, 여러 입력은 inputs[].fields에서 필드 ID·이름·실제 값을 선언 순서로 읽습니다.
4. producer_id로 그 값을 만든 활동을 찾아 앞선 실제 결과와 비교합니다.
5. realized.gooo를 다음 개발의 입력으로 사용합니다.

외부 기록 입력과 기록 기대값은 정확한 필드 이름과 명시적 문자열을 가진 완전한 JSON 객체입니다. 멤버 순서는 자유이며, 각 문자열은 UTF-8 1,024바이트까지 받습니다. 누락·중복·추가 필드와 null·타입 오류는 생성 전에 결과로 안내합니다.

완전성과 비용의 관측

같은 여섯 활동 그래프의 열두 반복 제어에서 출력 432/432, 입력 슬롯 648개, 연결 전달값 432개, 필드 관측 1,152개, 실제 실행 24회를 확인했습니다. 필드 관측은 입력과 출력 위치를 합하며, 같은 값이 여러 연결에 등장할 수 있습니다.

별도의 동시 두 요청은 72/72로 완료됐고, 새로운 실행 입력 여덟 개를 두 저장 구성에 전달해 96/96을 확인했습니다. 저장 재실행의 새 추론은 0회입니다. 상태 기대값 하나만 ready에서 wait로 바꾸면 35/36, 즉 97.22%로 기록됩니다. 실제 상태 값과 미충족 기대값도 같이 보입니다. 이 비율의 분모는 작성한 유한 기대값이며, 더 많은 기능을 요구하면 그 기대값을 추가해 관측합니다.

실제 추론 중앙값은 26.9μs, 전체 그래프 생성은 모델 12.80ms·결정론 11.77ms, 빌드·실행을 포함한 명령은 약 344ms·335ms였습니다. 최대 관측 메모리는 약 83MiB이며 자식 빌드 비용이 포함됩니다. 후보는 모델 2개·결정론 8개를 확인했지만, 이번 표본의 전체 생성 시간은 모델 쪽이 조금 길었습니다. 호스트 CPU 상승량은 별도로 측정하지 않았습니다.

원본·측정·재현 코드.

설치본과 필드별 요약

설치본의 별도 열두 관측도 출력 432/432·필드 관측 1,152개와 같은 생성 지문을 유지했습니다. 실제 추론 중앙값은 29.7μs, 생성은 모델 13.17ms·결정론 12.01ms, 명령 전체는 약 353ms·347ms입니다. 외부 기록을 받아 지역값 전체를 교체하는 다른 예제는 새 생성·저장 재실행에서 각 출력 8/8·출력 필드 8/8을 충족했습니다.

별도 연구 저장소의 Go 도구가 숫자와 미충족 필드를 요약합니다. 도구와 설치 관측은 PR #10의 21개 검사 후 main에 병합됐습니다. 이 커밋의 체크아웃 루트에서 다음 명령을 실행할 수 있습니다.

go run ./cmd/record-completeness \
  --input publication/native-record-values-20261004/installed/partial.json

출력과 기록 출력 필드는 각각 35/36 (97.22%)이며, Propose.state의 실제 ready와 기대 wait를 안내합니다. 기록 기대값을 생략한 실제 실행에서는 해당 출력 필드 36개를 미관측으로 표시하고 필드 점수는 0/0·비율은 미관측으로 남깁니다. 입력·출력의 필드 관측 1,152개와 기대 출력 필드의 분모는 각자의 의미를 유지합니다. --json으로 사례·활동·필드와 차이를 다음 작업에 전달할 수 있습니다. 설치본 원본과 비용.

다음에는 기록 필드의 선택지를 assembling에 표현하고, 기대 필드와 빠진 부분을 CLI가 바로 요약하며, 컴파일한 그래프를 재사용하는 방식으로 진행합니다. 등록형 도메인 실행 경로의 #874는 해당 계약을 계속 다룹니다.

다음 작은 실험: 모델이 기록의 내용을 고릅니다

아래는 다음 구현의 계획입니다. 현재 설치 기능과 관측은 위 절에서 구분합니다.

Gooo가 서류의 양식과 허용할 부품을 정하고, 모델이 각 칸에 넣을 부품을 고르는 구조로 시작합니다. 예를 들어 제목은 허용된 문자열 입력 중에서, 상태는 선언한 두 문자열 중에서 선택합니다. 조건은 선언한 Boolean 입력을 참조합니다. 모델이 제안할 대상은 타입이 맞는 완전한 기록 본문의 유한 목록입니다.

맡기는 결정	언어가 먼저 정할 것	확인할 관측
제목·요약의 참조 선택	허용할 입력 위치·필드 ID·문자열 타입	예상 필드값과 실제값의 일치
상태·사유 값 선택	허용된 값과 조건의 대안	참·거짓 양쪽에서의 기능 충족
다음 후보 선택	시도 예산과 남은 후보	실패 필드, 평가 수, 선택 순위
생성 결과 이어 쓰기	기준 본문과 고른 선택의 체크포인트	다음 생성의 소스·코드 일치

첫 실험은 지금 지원하는 필수 문자열 기록과 세 개의 이진 선택 정도로 범위를 잡습니다. 타입과 필드 채움은 컴파일러가 확인하고, 실제 기능은 작성한 기대값으로 측정합니다. 예산 안에서 가장 많이 충족한 후보와 남은 필드를 기록해 다음 작업의 입력으로 사용합니다. 한 번에 모든 사례를 맞추는 수치와 예산 후 충족 수를 따로 남깁니다.

실행·중간 연결은 Go로 구성합니다. 필드 위치는 선언 순서의 배열 인덱스로 표현하고, 완성된 함수는 현재 값 구조체로 낮춥니다. 먼저 결정론적 경로를 측정한 뒤 작은 판단기를 연결해 후보 확인 감소와 추가 추론 비용을 비교합니다. 새 특징이나 가중치를 만들면 기존 정수 판단기의 관측과 각각의 소스·학습 집합을 구분합니다. 같은 언어 양식의 작은 판단부터 키워 학습 범위를 제한합니다.